> 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
