Horton

Thread

  1. pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Bruce Momjian - CVS <momjian@postgresql.org> — 2008-07-16T16:54:08Z

    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)

  2. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Simon Riggs <simon@2ndquadrant.com> — 2008-07-16T20:13:24Z

    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

  3. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Bruce Momjian <bruce@momjian.us> — 2008-07-16T20:24:00Z

    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. +

  4. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Simon Riggs <simon@2ndquadrant.com> — 2008-07-16T20:39:38Z

    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

  5. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Neil Conway <neilc@samurai.com> — 2008-07-16T21:59:56Z

    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

  6. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Simon Riggs <simon@2ndquadrant.com> — 2008-07-16T23:06:10Z

    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

  7. Re: [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Tom Lane <tgl@sss.pgh.pa.us> — 2008-07-17T05:35:05Z

    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

  8. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    NikhilS <nikkhils@gmail.com> — 2008-07-17T05:46:40Z

    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

  9. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Simon Riggs <simon@2ndquadrant.com> — 2008-07-17T07:48:58Z

    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

  10. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Dave Page <dpage@pgadmin.org> — 2008-07-17T08:00:53Z

    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

  11. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Simon Riggs <simon@2ndquadrant.com> — 2008-07-17T08:26:45Z

    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

  12. Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

    Bruce Momjian <bruce@momjian.us> — 2008-07-18T02:10:46Z

    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. +