Re: [HACKERS] Primary key requires SERIAL

At 11:19 PM 11/18/99 -0500, Bruce Momjian wrote:
>> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> > We currently only allow the words PRIMARY KEY on a SERIAL column.
>> 
>> Say what?  There are ColConstraintElem and ConstraintElem productions
>> for PRIMARY KEY ... are they broken?
>> 
>>             regards, tom lane
>> 
>
>Oh, I see it now.  The grammer seems to only support it in SERIAL, but I
>see it works now.  I guess i am surprised SERIAL PRIMARY creates the
>index and sequence, while INTEGER PRIMARY only creates the index.

Oops, I guess I blew it by responding to a post by Bruce assuming he
was right.

Postgres supports a quasi-serial type by creating an index and
sequence (while Sybase supports it more transparently)

Postgres REALLY supports sequences much like Oracle (and others?
I don't know, my DB knowledge is very sketchy).  In Oracle, if
you define a primary key of type integer and want to sequence
it, you define a sequence and use "sequence_name.nextval" and
"sequence_name.currval".  This is very much like "nextval" and
"currval" in Postgres, and I presume no accident.

And in Oracle you create the sequence by hand - just like you do
in Postgres.

Personally, I think maintaining an "Oracle-ish" framework is wise,
for the simple selfish reason that I'm interested in porting 
Oracle-dependent SQL to Postgres.

If being "Oracle-ish" is still a goal (it was once a goal of at
least some of the implementors, it's obvious) then generating
the sequence just makes porting more difficult.

Actually, I think the inclusion of "serial" as a more integrated
type and leaving primary key stuff alone for existing types is
what makes sense.  You could provide a higher level of Sybase
portability without messing up us Oracle-derived folk.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.