From: | Aleksander Kmetec <aleksander(dot)kmetec(at)intera(dot)si> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Unpredicatable behavior of volatile functions used |
Date: | 2007-01-15 18:03:28 |
Message-ID: | 45ABC1F0.3010100@intera.si |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Aleksander Kmetec <aleksander(dot)kmetec(at)intera(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Oisin Glynn | 2007-01-15 18:03:32 | NOTIFY QUESTION |
Previous Message | Ardian Xharra | 2007-01-15 16:36:16 | Re: Why the data changes it's value by itself! |