Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Hmm. How far away are we from doing SERIAL in a way that you find more
> acceptable than the current technique of mucking around internally with
> sequences and default values?
I'd say "won't happen for 7.2", whereas it seems like changing sequences
to use int8 is something that could get done this month.
A true SERIAL type is something that we should think about along with
per-table OID generation, since they have essentially the same
requirement: a lightweight sequence generator. Our present approach of
a one-row table to represent a sequence is not sufficiently lightweight,
IMHO, either from an implementation or a conceptual viewpoint. (In
particular, it requires each sequence to have a unique name taken from
the table namespace, whereas for both table OIDs and serial columns
I think we'd much prefer the sequences to be anonymous ... or at least
in a different namespace. But how do we change that without breaking a
lot of existing application code?)
Offhand I don't see that adding a SERIAL8 type to the mix (or just
changing SERIAL to be int8) would make this any harder or easier.
The underlying implementation is exposed just as much as before,
but not any more so.
> If we do blast ahead with a SERIAL8, then we should consider
> implementing a SERIAL4 and then aliasing SERIAL to one or the other (can
> be done in the parser as you know).
Sure, that'd be a reasonable way to set it up, if we decide to have two
SERIAL types.
regards, tom lane