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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: phb(dot)emaj(at)free(dot)fr, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6683: dropping a table with a serial column from an extension needs to explicitely drop the associated seq
Date: 2012-06-10 12:57:12
Message-ID: 14871.1339333032@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> writes:
> On 06/10/2012 06:14 AM, Tom Lane wrote:
>> phb(dot)emaj(at)free(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message stormbyte 2012-06-10 16:58:31 BUG #6686: plpgsql Can't assign a variable with the output of a SQL Sentence which is not a SELECT
Previous Message Craig Ringer 2012-06-10 11:25:06 Re: BUG #6685: Concurrency fault in create table