Tom Lane wrote:
This is not legally optimizable into an indexscan, because currval() isI am not sure what you mean by a "volatile function", and how this affect the returned types, I guess this demands some more low level PG knowledge to understand.
a volatile function. (It's easy to construct cases where its value
actually does change from row to row --- just use a nextval() as well.)
You can fake it out in a couple of ways --- the recommended method is to
wrap currval in a user-defined function that is misleadingly marked
stable. I think it still works to just put the call in a sub-select:
select * from sale where id = (select currval( 'sale_id_seq' ));
but I take no responsibility if future improvements in the planner break
that trick.
The select trick works just fine, but I don't understand why :-(
Do you have any idea to how I may learn more about function types, or is this a "read the source, luke" thing (I am not sure I have time for that right now) ?
Well, thanks anyway ... this just work so nice, and I a looking forward to fill up this database with plenty of data, and still being able to sleep :-)
/BL
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
