Tom Lane wrote:
Aleksander Kmetec <aleksander.kmetec@xxxxxxxxx> 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
