One thing that would have to be thought about is whether the SERIAL
pseudo-type should generate an int8 instead of int4 column. On
compatibility grounds, it might be better to leave it generating int4,
and invent a second pseudo-type SERIAL8 that is just the same except
for making an int8 column. I'm more worried about changing the datatype
of a user column than I am about changing the output type of nextval(),
so I'd be sort of inclined to have two SERIAL types even if we change
nextval() to int8. Thoughts?
Hmm. How far away are we from doing SERIAL in a way that you find more
acceptable than the current technique of mucking around internally with
sequences and default values? Changes there may not be impacted by
decisions we make now on an int8 type, but it might be good to think
about it beforehand.

If we do blast ahead with a SERIAL8, then we should consider
implementing a SERIAL4 and then aliasing SERIAL to one or the other (can
be done in the parser as you know).

- Thomas

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 11 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 6, '01 at 8:27p
activeAug 7, '01 at 2:53p
posts11
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase