Re: BUG #6683: dropping a table with a serial column from an extension needs to explicitely drop the associated seq - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6683: dropping a table with a serial column from an extension needs to explicitely drop the associated seq
Date
Msg-id 14871.1339333032@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6683: dropping a table with a serial column from an extension needs to explicitely drop the associated seq  (Craig Ringer <ringerc@ringerc.id.au>)
List pgsql-bugs
Craig Ringer <ringerc@ringerc.id.au> writes:
> On 06/10/2012 06:14 AM, Tom Lane wrote:
>> phb.emaj@free.fr writes:
>>> When a table having a seial column has been created by a CREATE EXTENSION,
>>> and when this table is later dropped from the extension, the associated
>>> sequence must be also explicitely dropped from the extension.

>> This doesn't really seem like a bug to me.  The sequence is a somewhat
>> independent object.

> I disagree; it is inconsistent with the expectation established in
> normal operations that the sequence created to serve a SERIAL column is
> owned by that table/column and is dropped when it is.

But we're not talking about a DROP; we're talking about disassociating
it from an extension.  That's a sufficiently unusual thing to do that
I think it dangerous to make any assumptions about why the extension
author is doing that, or whether he wants the sequence to come too.
In the reverse direction, ALTER EXTENSION ADD TABLE doesn't auto-add
associated sequences either.

If we did do something like this, pg_dump would need some complicated
and fragile logic additions to understand the implications; for
instance, if it saw an owned sequence that wasn't a member of the
extension, it would have to know to issue an ALTER EXTENSION DROP
SEQUENCE after adding the table.  (Now admittedly, I'm on record as
wanting to get rid of pg_dump having to do anything with extension
members, but still it's a great example of why "helpful" automatic
actions aren't necessarily a good thing.)

            regards, tom lane

pgsql-bugs by date:

Previous
From: Craig Ringer
Date:
Subject: Re: BUG #6685: Concurrency fault in create table
Next
From: Tom Lane
Date:
Subject: Re: BUG #6685: Concurrency fault in create table