On Sat, 2006-04-29 at 17:54 -0400, Tom Lane wrote:
> In some recent activity on the patches list about responding to bug #2073,
> we've been discussing various possible tweaks to the behavior of dropping
> or modifying a serial column. The hacks involved with SERIAL seem to me
> to be getting uglier and uglier, and I think it's time to take a step
> back and consider what we really want SERIAL to act like.
> It seems to me there are two basic philosophies at war here:
> 1. A serial column is a "black box" that you're not supposed to muck with
> the innards of.
> 2. A serial declaration is just a "macro" for setting up a sequence and a
> column default expression. This was the original viewpoint and indeed is
> still what it says in the documentation:
> Comments, other opinions?
Do both. Return SERIAL to being a macro and implement the SQL IDENTITY
construct as the black box version.
CREATE TABLE foo (bar integer PRIMARY KEY GENERATED BY DEFAULT
INSERT ... RETURNS needs to be implemented before SERIAL can become a
black box. Until that time we will still need some knowledge of the
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2006-04-30 02:24:48|
|Subject: Re: inet increment with int|
|Previous:||From: Tom Lane||Date: 2006-04-30 00:58:42|
|Subject: Handling conflicting FOR UPDATE/SHARE specs|