Re: [HACKERS] Sequences....

> "D'Arcy" "J.M." Cain <darcy(at)druid(dot)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