Re: Unpredicatable behavior of volatile functions used

Tom Lane wrote:
> Aleksander Kmetec <aleksander.kmetec@intera.si> writes:
>> Some quick testing shows that util.row_number() only gets re-evaluated at every call if the subquery contains an
ORDER 
>> BY clause. Now we can predict whether we need to compensate for that just by looking at the original query.
>
> If you're going to use a cursor, I don't understand why you don't just
> MOVE FORWARD ALL and look at the returned rowcount to determine how
> many rows in the query.  This won't be any more expensive than fetching
> the last row ...

That's a very good question...

It's more than a year now since I originally wrote that code, and I remember testing MOVE FORWARD ALL, but being unable

to get my hands on the row count for that operation. At that time I just accepted it as the way things work and created

that row_number() workaround instead.

But after your last message I went to investigate why that had happened in the first place. And sure enough, there was
a 
bug in the 3rd party database library we're using. After a quick fix everything is working as it should and I can
remove 
  row_number() altogether.

Thank you for your patience. :-)

Aleksander