Billy G. Allie wrote:
Vadim B. Mikheev wrote:
does"? I can envision where using currval() before nextval() can be useful.
Vadim B. Mikheev wrote:
Billy G. Allie wrote:
first.I encountered a problem (bug? feature?) where "select currval('sequence')"
will generate an error if "select nextval('sequence')" is not executed
will generate an error if "select nextval('sequence')" is not executed
This is feature :)
1. This is what Oracle does.
2. currval () is described as returning value returned by
last nextval() in _session_.
Vadim
Does this mean we should not modify this behavior because "this is what Oracle1. This is what Oracle does.
2. currval () is described as returning value returned by
last nextval() in _session_.
Vadim
does"? I can envision where using currval() before nextval() can be useful.
This was changed to be more consistent with 1. & 2. (note - not only 1.,
but 2. also).
But personally I haven't objection against changing this again.
Men, vote pls!
Vadim
No, I would not change this again, my question is iff instead of elog(ERROR
the old code could be reinserted. This would mean, that when a session did a
previous nextval it gets it's session currval, but if it did not, it gets a global
currval as in previous implementation. The problem is somebody who
calls currval often without ever calling nextval (like a monitor) will totally kill
performance. (same as a select max(field))
Andreas