I wrote:
> The easiest answer I can think of at the moment is to run parse analysis
> for a DECLARE CURSOR and then throw away the result. To avoid this
> overhead in cases where it's useless, we could probably teach analyze.c
> to do it only if p_variableparams is true (which essentially would mean
> that the DECLARE CURSOR came in via PQprepare or equivalent, and not as
> a simply executable statement).
> Plan B would be to promote DECLARE CURSOR to an "optimizable statement"
> that is treated under the same rules as SELECT/UPDATE/etc, in particular
> that we assume locks obtained at analysis are held through to execution.
> This might be a cleaner answer overall, but I have no idea right now
> about the effort required or any possible downsides.
I looked into Plan B a bit more, and decided that the least ugly way to
deal with DECLARE CURSOR is to treat it a bit like SELECT INTO: it is a
SELECT for purposes of parsing and planning, and then we have to divert
just before calling the executor. This would require special-casing in
pretty nearly just the same places that currently treat SELECT INTO as
a special case. The query representation would be:
In raw grammar output: same as now, ie, a DeclareCursorStmt with a
raw SelectStmt tree below it.
After parse analysis: a CMD_SELECT Query with nonempty utilityStmt
(the original DeclareCursorStmt, but with its query field now NULL
since we don't need the raw grammar output anymore; or maybe we should
invent a separate node type for the purpose).
After planning: a PlannedStmt. Just as PlannedStmt carries an "into"
field for SELECT INTO, it'd have to carry a field for DECLARE CURSOR.
There seem to be enough places that know about SELECT INTO that this'd
be a bit tedious to do --- most of a day's work probably. Is it worth
the trouble, or should I just do the klugy fix? Thoughts?
regards, tom lane