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