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,
> http://archives.postgresql.org/pgsql-bugs/2005-11/msg00303.php
> 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
AS IDENTITY);
INSERT ... RETURNS needs to be implemented before SERIAL can become a
black box. Until that time we will still need some knowledge of the
sequence involved.
--
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
