Re: SERIAL type feature request - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: SERIAL type feature request
Date
Msg-id 43928670.5080508@Yahoo.com
Whole thread Raw
In response to SERIAL type feature request  (Zoltan Boszormenyi <zboszor@dunaweb.hu>)
Responses Re: SERIAL type feature request  (Zoltan Boszormenyi <zboszor@dunaweb.hu>)
List pgsql-hackers
On 12/3/2005 4:23 PM, Zoltan Boszormenyi wrote:

> Hi!
> 
> I would like to add an entry to PostgreSQL 8.2 TODO:
> - Extend SERIAL to a full-featured auto-incrementer type.
> 
> To achieve this, the following three requirements should be fulfilled:
> 
> 1. The statement parser should be able to handle this:
> 
> create table x (
>     id serial(N),
>     ...
> );
> 
> and behind the scenes this would translate into the "create sequence ... 
> start N"
> before creating the table.

Syntactic sugar with zero real value. A setval() after create table does 
exactly the same. Unless you extend your proposal to unambiguosly 
specify any or all of the serials properties (min, max, start, cache, 
cycle), this has to be rejected as incomplete.

> 
> 2. Upon INSERTing to a serial column, explicitly given 0 value or 
> 'default' keyword
> or omitted field (implicit default) should be interchangeable.

Why exactly would we treat an explicit zero different from any other 
explicit value? What you are asking for is to substitute an explicit, 
literal value presented by the user with something different. Sorry, but 
if Informix does THAT, then Informix is no better than MySQL.

> 
> 3. When a serial field value is given in an INSERT or UPDATE statement
> and the value is larger the the current value of the sequence then the 
> sequence
> should be modified accordingly.

How about negative increment values, cycling sequences and max/minval?

> 
> This is the way Informix handles its serial type, although it doesn't seem
> to have a visible sequence bound to the serial column.

Have you considered asking Informix to do the reverse changes?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_restore [archiver] file offset in dump file is too
Next
From: "Mario Weilguni"
Date:
Subject: Re: Strange left join problems in 8.1