Обсуждение: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
От
momjian@postgresql.org (Bruce Momjian)
Дата:
Log Message:
-----------
Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Modified Files:
--------------
pgsql/src/backend/commands:
tablecmds.c (r1.259 -> r1.260)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c?r1=1.259&r2=1.260)
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
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. +
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
On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote: > TRUNCATE foo; > TRUNCATE foo; > > works well. > > So why do we need > > TRUNCATE foo, foo; For the sake of completeness? Having "TRUNCATE foo, foo" fail would be rather inconsistent. -Neil
On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote: > On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote: > > TRUNCATE foo; > > TRUNCATE foo; > > > > works well. > > > > So why do we need > > > > TRUNCATE foo, foo; > > For the sake of completeness? Having "TRUNCATE foo, foo" fail would be > rather inconsistent. Inconsistent with what exactly? If a proposal to support this was made on hackers, it would be laughed away. It is not required for functionality, usability, standards compliance, backwards compatibility, robustness, performance, internal coding simplicity, portability, marketing or external compatibility. For what reason would we do it? Nobody has said. And as I pointed out, other commands fail in similar circumstances. Consistency is required, but consistency in making balanced judgements about feature additions. Our users will be surprised to find this was at the top of our list ahead of other patches during a commit fest, other agreed TODO items and other proposals from users. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Hi Simon,
--
EnterpriseDB http://www.enterprisedb.com
On Thu, Jul 17, 2008 at 4:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
I presented a simple psql version here. I was actually processing multiple relations in my C library in which truncate was invoked on all the involved relations. I was passing a list of these rels to ExecuteTruncate which barfed when the same rel was mentioned twice in that list. Its really an implementation issue as Tom mentioned.
Regards,
Nikhils
On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
> On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> > TRUNCATE foo;
> > TRUNCATE foo;
> >
> > works well.
> >
> > So why do we need
> >
I presented a simple psql version here. I was actually processing multiple relations in my C library in which truncate was invoked on all the involved relations. I was passing a list of these rels to ExecuteTruncate which barfed when the same rel was mentioned twice in that list. Its really an implementation issue as Tom mentioned.
Regards,
Nikhils
Inconsistent with what exactly?
> > TRUNCATE foo, foo;
>
> For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
> rather inconsistent.
If a proposal to support this was made on hackers, it would be laughed
away. It is not required for functionality, usability, standards
compliance, backwards compatibility, robustness, performance, internal
coding simplicity, portability, marketing or external compatibility. For
what reason would we do it? Nobody has said.
And as I pointed out, other commands fail in similar circumstances.
Consistency is required, but consistency in making balanced judgements
about feature additions.
Our users will be surprised to find this was at the top of our list
ahead of other patches during a commit fest, other agreed TODO items and
other proposals from users.Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
--
EnterpriseDB http://www.enterprisedb.com
On Thu, 2008-07-17 at 11:16 +0530, Nikhils wrote: > I presented a simple psql version here. I was actually processing > multiple relations in my C library in which truncate was invoked on > all the involved relations. I was passing a list of these rels to > ExecuteTruncate which barfed when the same rel was mentioned twice in > that list. Its really an implementation issue as Tom mentioned. So you think we should change Postgres rather than your program? Many people think that on list, and are ignored. Why no bug report, proposal or patch? Why during a commit fest? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
On Thu, Jul 17, 2008 at 8:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Thu, 2008-07-17 at 11:16 +0530, Nikhils wrote: > > >> I presented a simple psql version here. I was actually processing >> multiple relations in my C library in which truncate was invoked on >> all the involved relations. I was passing a list of these rels to >> ExecuteTruncate which barfed when the same rel was mentioned twice in >> that list. Its really an implementation issue as Tom mentioned. > > So you think we should change Postgres rather than your program? > Many people think that on list, and are ignored. > > Why no bug report, proposal or patch? Why during a commit fest? Huh? There was a bug report, with suggested fix on June 5th from Nikhil - http://archives.postgresql.org/pgsql-hackers/2008-06/msg00231.php No-one responded, and over a month later Bruce fixed the bug, pointing out that TRUNCATE is now consistent with LOCK. The fact that Bruce fixed it during a commit fest is irrelevant. Bug fixes don't stop for commit fests, feature freeze's or even releases in many cases - and surely we're not going to tell Bruce he cannot distract himself with a totally different task for 30 minutes or however long it took? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thu, 2008-07-17 at 09:00 +0100, Dave Page wrote: > On Thu, Jul 17, 2008 at 8:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > > > On Thu, 2008-07-17 at 11:16 +0530, Nikhils wrote: > > > > > >> I presented a simple psql version here. I was actually processing > >> multiple relations in my C library in which truncate was invoked on > >> all the involved relations. I was passing a list of these rels to > >> ExecuteTruncate which barfed when the same rel was mentioned twice in > >> that list. Its really an implementation issue as Tom mentioned. > > > > So you think we should change Postgres rather than your program? > > Many people think that on list, and are ignored. > > > > Why no bug report, proposal or patch? Why during a commit fest? > > Huh? There was a bug report, with suggested fix on June 5th from > Nikhil - http://archives.postgresql.org/pgsql-hackers/2008-06/msg00231.php > > No-one responded, and over a month later Bruce fixed the bug, pointing > out that TRUNCATE is now consistent with LOCK. > > The fact that Bruce fixed it during a commit fest is irrelevant. Bug > fixes don't stop for commit fests OK, my mistake. Comments withdrawn, with apologies. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
Simon Riggs wrote: > > Huh? There was a bug report, with suggested fix on June 5th from > > Nikhil - http://archives.postgresql.org/pgsql-hackers/2008-06/msg00231.php > > > > No-one responded, and over a month later Bruce fixed the bug, pointing > > out that TRUNCATE is now consistent with LOCK. > > > > The fact that Bruce fixed it during a commit fest is irrelevant. Bug > > fixes don't stop for commit fests > > OK, my mistake. Comments withdrawn, with apologies. The ugly truth is that my schedule is now so crazy with travel that I am having to catch up with community emails that need attention anytime I have the chance, rather than at appropriate times. Recent schedule: -1 week, church mission trip to Pittsburgh +1 week, OSCON +3 weeks, Linuxworld +6 weeks, Brasilia conference -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +