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

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bruce Momjian <momjian(at)postgresql(dot)org>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Date: 2008-07-16 20:13:24
Message-ID: 1216239204.19656.416.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers


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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2008-07-16 20:24:00 Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Previous Message Tom Lane 2008-07-16 19:33:25 pgsql: Fix previous patch so that it actually works --- consider

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-07-16 20:24:00 Re: pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.
Previous Message Dimitri Fontaine 2008-07-16 19:55:40 Re: Postgres-R: current state of development