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.
