Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
От | Simon Riggs |
---|---|
Тема | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. |
Дата | |
Msg-id | 1216240778.19656.419.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pgsql: Allow TRUNCATE foo, foo to succeed, per
report from Nikhils.
|
Список | pgsql-committers |
Yes, TRUNCATE foo; TRUNCATE foo; works well. So why do we need TRUNCATE foo, foo; --------------------------------------------------------------------------- On Wed, 2008-07-16 at 16:24 -0400, Bruce Momjian wrote: > Logically, you should be able to truncate a table twice. > > --------------------------------------------------------------------------- > > Simon Riggs wrote: > > > > On Wed, 2008-07-16 at 16:54 +0000, Bruce Momjian wrote: > > > Log Message: > > > ----------- > > > Allow TRUNCATE foo, foo to succeed, per report from Nikhils. > > > > What's the use case for this? > > > > It's not compatibility, is it? Why would you ever do that? If you did, > > why would you expect it to work? Seems more likely to be a user error > > than a real request. > > > > Should it throw one trigger call, or two? > > > > BTW, create index foo_idx on foo (col1, col1) fails also with a strange > > error message. Should we silently merge columns and ignore that also? > > > > ERROR: duplicate key value violates unique constraint > > "pg_attribute_relid_attnam_index" > > > > Seems easier to throw errors for weird DDL like this. > > > > e.g. create index concurrently on foo (col1); creates an index called > > "concurrently" on foo, while holding locks... > > > > -- > > Simon Riggs www.2ndQuadrant.com > > PostgreSQL Training, Services and Support > -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-committers по дате отправления: