From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] BUG #3244: problem with PREPARE |
Date: | 2007-04-27 16:22:24 |
Message-ID: | 15797.1177690944@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | DNS | 2007-04-27 18:23:29 | PGSQL - WARNING: 25P01: there is no transaction in progress |
Previous Message | Heikki Linnakangas | 2007-04-27 08:44:16 | Re: [BUGS] BUG #3245: PANIC: failed to re-find shared lock object |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-04-27 16:51:05 | Re: Windows installer for 8.3 - dev release for testing |
Previous Message | Dave Page | 2007-04-27 16:21:36 | Windows installer for 8.3 - dev release for testing |