SERIAL problems?

Started by Zoltan Boszormenyiover 19 years ago2 messages
#1Zoltan Boszormenyi
zboszor@dunaweb.hu

Hi,

I just saw these in the TODO list:

o %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
o %Disallow ALTER SEQUENCE changes for SERIAL sequences
because pg_dump does not dump the changes

What are the "existing problems"?

I am asking because I am experimenting to implement
the SQL2003 compliant form for the serial type
to be able specify the underlying sequence
parameters:

SERIAL [ GENERATED [ ALWAYS | BY DEFAULT ]
AS IDENTITY (
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ]
[ MAXVALUE maxvalue | NO MAXVALUE ]
[ START [ WITH ] start ]
[ CACHE cache ]
[ [ NO ] CYCLE ]
) ]

Best regards,
Zolt�n B�sz�rm�nyi

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Zoltan Boszormenyi (#1)
Re: SERIAL problems?

Zoltan Boszormenyi <zboszor@dunaweb.hu> writes:

What are the "existing problems"?

Please read the archives; this has been discussed recently.
There's a lot of disagreement about what ALTER should allow
and what pg_dump should do with an altered sequence.

I am asking because I am experimenting to implement
the SQL2003 compliant form for the serial type
to be able specify the underlying sequence
parameters:

Be aware that the big problem with SQL2003 is that it expects an
"action at a distance" behavior whereby different references to a
generator all return the same result if executed within the same
query cycle. This makes the construct not equivalent to either
nextval() or currval(), but some hybrid with hidden state; and
changing of that state would have to tie into core parts of the
executor. It looks pretty messy :-(

regards, tom lane