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

NikhilS <nikkhils@gmail.com>

From: Nikhils <nikkhils@gmail.com>
To: "Simon Riggs" <simon@2ndquadrant.com>
Cc: "Neil Conway" <neilc@samurai.com>, "Bruce Momjian" <bruce@momjian.us>, pgsql-committers@postgresql.org
Date: 2008-07-17T05:46:40Z
Lists: pgsql-hackers
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