Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
От | Bruce Momjian |
---|---|
Тема | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. |
Дата | |
Msg-id | 200807162024.m6GKO0118971@momjian.us обсуждение исходный текст |
Ответ на | Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: pgsql: Allow TRUNCATE foo, foo to succeed, per
report from Nikhils.
|
Список | pgsql-committers |
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 -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-committers по дате отправления: