Tom Lane wrote:
Aleksander Kmetec <[EMAIL PROTECTED]> 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 y
Aleksander Kmetec <[EMAIL PROTECTED]> 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 goin
Tom Lane wrote:
This isn't gonna work very well if your query involves sorting, because
the SELECT-list is evaluated before the sort step ...
regards, tom lane
Thanks, this seems to solve my problem.
Some quick testing shows that util.row_number() only gets re-evalua
Aleksander Kmetec <[EMAIL PROTECTED]> writes:
> We're using the following technique for counting the number of rows in a
> cursor:
> DECLARE instance_cur_1 SCROLL CURSOR FOR
> SELECT util.row_number(), *
> FROM (
> $LONG_RUNNING_QUERY
> ) ss
> FETCH LAST IN instance_cur_1;
> util.row_number
Hi,
I'm running into some inconsistent behavior when using volatile functions with
cursors under PG 8.1.
We're using the following technique for counting the number of rows in a cursor:
---
DECLARE instance_cur_1 SCROLL CURSOR FOR
SELECT util.row_number(), *
FROM (
$LONG_RUNNIN
