Re: [HACKERS] Sequences.... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Sequences....
Date
Msg-id 199903171814.NAA11821@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Sequences....  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Sequences....
List pgsql-hackers
> "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 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.

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

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.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Subqueries and indexes
Next
From: Terry Mackintosh
Date:
Subject: Re: [Fwd: Re: [HACKERS] Sequences....]