Re: Sequences/defaults and pg_dump

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, nikolay(at)samokhvalov(dot)com, PostgreSQL-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Sequences/defaults and pg_dump
Date: 2006-02-08 18:57:09
Message-ID: 20060208185709.GA9036@mcknight.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Feb 08, 2006 at 09:03:54AM -0500, Bruce Momjian wrote:
> Joachim Wieland wrote:
> > On Tue, Feb 07, 2006 at 09:49:02AM -0500, Bruce Momjian wrote:
> > > > The correct solution to this is to forbid ALTER COLUMN SET DEFAULT on
> > > > a serial column, but we haven't gotten around to enforcing that yet.

> > > TODO has:

> > > * %Disallow changing default expression of a SERIAL column

> > This should go along with another command like

> > ... ALTER COLUMN DROP SERIAL

> > which drops the serial and removes the dependencies to get rid of it in a
> > clean way, right?

> Uh, you can drop a column or change its data type, but not drop the data
> type of a column.

Sure, the "DROP SERIAL" I proposed would rather "change" the data type
to int by dropping the default and would delete referring pg_depend entries.
Read it more as a kind of "drop autoincrement functionality for this
column".

The problem I see (but you might see it differently) is that you can't drop
this autoincrement stuff without also dropping the column once you forbid to
change the default (yeah I know, changing the default is even worse and
leaves you with incorrect dependencies).

Joachim

--
Joachim Wieland joe(at)mcknight(dot)de
C/ Usandizaga 12 1°B ICQ: 37225940
20002 Donostia / San Sebastian (Spain) GPG key available

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Philippe Ferreira 2006-02-08 19:12:37 Re: wal copies for high availability
Previous Message Philippe Ferreira 2006-02-08 18:47:41 Re: Why pg_hba not in table?

Browse pgsql-hackers by date

  From Date Subject
Next Message Rick Gigger 2006-02-08 19:40:26 Re: [HACKERS] Audio interview
Previous Message Martijn van Oosterhout 2006-02-08 18:55:07 Re: Upcoming re-releases