"D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> Thus spake Ryan Bradetich
>> 2. Create a new data type serial. I haven't thought idea out much,
>> and need to investigate it some more. I'm thinking it would be binary
>> equivilent with the int4 type, and use most of the existing seqence
>> code, but not put the seqence name entry in the pg_class system
>> table. Does this sound like a feasible idea?
> I like it.
A binary-equivalent type does seem like a handier way to represent
SERIAL than what we are doing. You still need a way to find the
associated sequence object, though, so a table mapping from
table-and-column to sequence OID is still necessary. (Unless we
were to use the atttypmod field for the column to hold the sequence
object's OID? Seems a tad fragile though, since there's no way to
update an atttypmod field in an existing table.)
I don't like the idea of not putting the sequence name into pg_class.
That would mean that the sequence object is not directly accessible
for housekeeping operations. If you do that, you'd have to invent
all-new ways to do the following:* currval, setval, nextval (yes there are scenarios where a direct nextval on the
sequenceis useful)* dump and reload the sequence in pg_dump
> Alternatively, maybe we can enforce the serialism of the type. Even
> if the user specifies a value, ignore it and put the next number in
> anyway.
I don't like that at *all*.
> Do as above but allow the user to specify a number as long as it is
> available and is lower than the next number in the series.
I think better would be that the sequence value is silently forced to
be at least as large as the inserted number, whenever a specific number
is inserted into a SERIAL field. That would ensure we never generate
duplicates, but not require keeping any extra state.
> If we decide to leave things more or less as they are, how about a new
> flag for sequences and indexes that sets a row as system generated
> rather than user specified? We can then set that field when a sequence
> or index is generated by the system such as for the serial type or
> primary keys.
Yes, it'd be nice to think about fixing up primary-key implicit indexes
while we are at it --- they have some of the same problems as SERIAL ...
regards, tom lane
