Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. - Mailing list pgsql-committers

From Simon Riggs
Subject Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Date
Msg-id 1216249570.19656.441.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.  (Neil Conway <neilc@samurai.com>)
Responses Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.  (Nikhils <nikkhils@gmail.com>)
List pgsql-committers
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


pgsql-committers by date:

Previous
From: Neil Conway
Date:
Subject: Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Next
From: rlucas@pgfoundry.org (User Rlucas)
Date:
Subject: aupg - aupg_src: I am so ashamed to commit this patch.