Re: [HACKERS] Sequences....

> "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.)
> 
> atttypmod seems like a perfect idea.  We also need a unique type for
> large objects, so oid's and large objects can be distinguished.  We
> could do both at the same time, and with Thomas's new type coersion
> stuff, we don't need to create tons of functions for each new type.

I'll play around with this idea for a while and see what I come up with.  I'm 
not sure if I completely understand, but I'll form questions as I continue to 
dig into the source code. :)

> > 
> > 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 sequence is useful)
> >     * dump and reload the sequence in pg_dump
> 
> Yes, let's keep it in pg_class.  No reason not to.

Ok, you convicned me.

> > > 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 ...

I'm not following this... When a table is dropped, all the indexes for that 
table get dropped.  The indexes are associated with a table, whereas the 
sequences are just sequences not associated with a table.  Am I understanding 
the issue correctly?

> My guess is that 6.5 is too close to be making such sweeping changes,
> though the pg_dump problems with SERIAL certainly make this an important
> issue.

Do you want me to try and get the serial stuff finished before 6.5? or should we 
wait?

-Ryan