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