Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I still think we shouldn't be hashing this out during beta, but ...
>
> We're looking at ways to fix some bugs. It's never been the case that
> our first-resort response to a bug is "pull out features".
True, but your first guess was that none of this could be fixed in 8.2,
then you proposed a 50% fix that was user-visible. Given those options,
I do prefer removal of a minor feature.
> > What would the final nextval() behavior be? ::regclass binding? How
> > would late binding be done? What syntax?
>
> If I were prepared to say all that today, I would have just done it ;-)
>
> The more I think about it, the more I think that two sets of function
> names might not be such an awful idea. next_value(), curr_value(), and
> set_value() seem like they'd work well enough. Then we'd just say that
> nextval and friends are deprecated except when you need late binding,
> and we'd be done.
I don't like the val/value distinction (the added "ue" means what?).
Perhaps next_seq/curr_seq/set_seq would work more cleanly. I never
liked that the function names had no reference to "seq"uence in them.
Didn't next_val() come from Oracle? Does it make sense to make new
non-Oracle compatible commands for this, especially since Oracle
probably does early binding? What would make more sense perhaps would
be for next_val to do early binding, and a new function do late binding,
perhaps next_val_str().
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073