pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
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
Simon Riggs <simon@2ndquadrant.com> writes:
On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
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?
Well, it's certainly surprising that it fails entirely. And if we
actually wanted to reject the case, it should be drawing an apropos
error message. The fact is that this failure is just an implementation
issue.
Our users will be surprised to find this was at the top of our list
If it had taken more than five lines of code to fix, I might agree with
you. But we don't stop fixing bugs just because commitfest is on,
especially not trivial ones.
regards, tom lane
Hi Simon,
On Thu, Jul 17, 2008 at 4:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
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
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--
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.phpNo-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.phpNo-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 festsOK, 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. +