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, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
