Tom Lane wrote:
>This is not legally optimizable into an indexscan, because currval() is
>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.)
>
>
I 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.
>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
