From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: NEXT VALUE FOR... |
Date: | 2004-05-07 20:01:48 |
Message-ID: | 15538.1083960108@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Rod Taylor <pg(at)rbt(dot)ca> writes:
> Isn't there a statement level memory location that we could shove a
> boolean variable?
Not per se, and anyway remember that this behavior is per sequence
generator not global.
I was just mentally designing something that I think might work. We
need two data structures: the first is a List hanging off the EState,
containing one shared entry for each sequence generator used in the plan
tree. The entry contents look like:
OID of sequence object (search key for finding list entry)
number of calls (initially zero, see below)
latest result of underlying nextval function (initially unset)
The ExprState record for a NEXTVALUE node has to contain a number of
calls counter and a pointer to the appropriate shared entry.
ExecInitExpr can fill this in (creating the shared entry if not already
present).
Then the algorithm for evaluating NEXTVALUE looks like:
1. Increment local number-of-calls counter.
2. Compare local counter to shared counter.
2a. If local > shared: this is first NEXTVALUE call of a new per-row
cycle. Call underlying nextval(), store its result in the shared
entry, set shared number-of-calls counter equal to local, return
nextval result.
2b. If local = shared: this is a duplicate NEXTVALUE call. Just return
the nextval() value already stored in the shared entry.
2c. If local < shared: apparently we missed being called during the last
cycle. Advance local counter to equal shared, and return the
already-stored nextval() value.
I suppose you could also argue for raising an error in case 2c; this
would suggest that the user is violating one of the constraints in the
spec about where he can put NEXT VALUE FOR (like putting it inside a
CASE where it may not get evaluated on every query cycle). But I think
that would be overly anal retentive, given that we're not making a
complete attempt to enforce those spec restrictions.
This all assumes that associating the NEXTVALUE state with an EState
is a good approximation of the spec's statements about how often to
advance the sequence counter. I think it is all right for simple cases
but I'm not totally convinced it is right for complicated queries.
(Also, should NEXTVALUE calls inside a function track those outside?
I think the way the spec is worded, they shouldn't, but someone else
should read it too.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-05-07 20:32:50 | Re: [BUGS] BUG #1148: server restarts depending on stats options |
Previous Message | Rod Taylor | 2004-05-07 19:18:04 | Re: NEXT VALUE FOR... |