Обсуждение: PL/pgsql EXECUTE 'SELECT INTO ...'
I have looked a little bit at what it'd take to make SELECT INTO inside
an EXECUTE work the same as it does in plain plpgsql --- that is, the
INTO should reference plpgsql variables, not a destination table.
It looks to me like this is possible but would require some nontrivial
re-engineering inside plpgsql. What I'm visualizing is that EXECUTE
should read its string argument not just as an SPI_exec() string, but
as an arbitrary plpgsql proc_stmt. This would offer some interesting
capabilities, like building a whole FOR-loop for dynamic execution.
But there are a number of problems to be surmounted, notably arranging
for the parsetree built by the plpgsql compiler not to be irretrievably
memory-leaked. (That ties into something I'd wanted to do anyway,
which is to have the plpgsql compiler build its trees in a memory
context associated with the function, not via malloc().)
This does not look like something to be tackling when we're already
in late beta, unfortunately. So we have to decide what to do for 7.1.
If we do nothing now, and then implement this feature in 7.2, we will
have a backwards compatibility problem: EXECUTE 'SELECT INTO ...'
will completely change in meaning.
I am inclined to keep our options open by forbidding EXECUTE 'SELECT
INTO ...' for now. That's more than a tad annoying, because that leaves
no useful way to do a dynamically-built SELECT, but if we don't forbid
it I think we'll regret it later.
Comments?
regards, tom lane
On Wed, Feb 07, 2001 at 10:15:02PM -0500, Tom Lane wrote: > I have looked a little bit at what it'd take to make SELECT INTO inside > an EXECUTE work the same as it does in plain plpgsql ... > If we do nothing now, and then implement this feature in 7.2, we will > have a backwards compatibility problem: EXECUTE 'SELECT INTO ...' > will completely change in meaning. > > I am inclined to keep our options open by forbidding EXECUTE 'SELECT > INTO ...' for now. ... if [not] I think we'll regret it later. I agree, disable it. But put a backpatch into contrib along with a reference to this last e-mail. Anybody who cares enough can apply the patch, and will be prepared for the incompatibility. Nathan Myers ncm@zembu.com
Tom Lane wrote:
> I have looked a little bit at what it'd take to make SELECT INTO inside
> an EXECUTE work the same as it does in plain plpgsql --- that is, the
> INTO should reference plpgsql variables, not a destination table.
> It looks to me like this is possible but would require some nontrivial
> re-engineering inside plpgsql. What I'm visualizing is that EXECUTE
> should read its string argument not just as an SPI_exec() string, but
> as an arbitrary plpgsql proc_stmt. This would offer some interesting
> capabilities, like building a whole FOR-loop for dynamic execution.
> But there are a number of problems to be surmounted, notably arranging
> for the parsetree built by the plpgsql compiler not to be irretrievably
> memory-leaked. (That ties into something I'd wanted to do anyway,
> which is to have the plpgsql compiler build its trees in a memory
> context associated with the function, not via malloc().)
>
> This does not look like something to be tackling when we're already
> in late beta, unfortunately. So we have to decide what to do for 7.1.
> If we do nothing now, and then implement this feature in 7.2, we will
> have a backwards compatibility problem: EXECUTE 'SELECT INTO ...'
> will completely change in meaning.
>
> I am inclined to keep our options open by forbidding EXECUTE 'SELECT
> INTO ...' for now. That's more than a tad annoying, because that leaves
> no useful way to do a dynamically-built SELECT, but if we don't forbid
> it I think we'll regret it later.
You can do something like
FOR record_var IN EXECUTE <string-expr> LOOP ... END LOOP;
In this case, the <string-expr> executed over SPI_exec() must return tuples (0-n). Otherwise you'll get a runtime
error.
Inside the loop you have access to the tuples via the record. Is that the dynamically-built SELECT capability
you'vebeen missing?
There's not that much need for mucking with temp tables in EXECUTE as all this discussion looks to me.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <janwieck@Yahoo.com> writes:
>> I am inclined to keep our options open by forbidding EXECUTE 'SELECT
>> INTO ...' for now. That's more than a tad annoying, because that leaves
>> no useful way to do a dynamically-built SELECT, but if we don't forbid
>> it I think we'll regret it later.
> You can do something like
> FOR record_var IN EXECUTE <string-expr> LOOP
> ...
> END LOOP;
Okay, that solves the concern I had about not being able to get the
result of an EXECUTEd select at all. I'll go ahead and forbid
EXECUTE 'SELECT INTO' for the time being, and we can talk about
improving plpgsql later.
regards, tom lane
Tom Lane writes: > I am inclined to keep our options open by forbidding EXECUTE 'SELECT > INTO ...' for now. That's more than a tad annoying, because that leaves > no useful way to do a dynamically-built SELECT, but if we don't forbid > it I think we'll regret it later. You can always use CREATE TABLE AS. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I am inclined to keep our options open by forbidding EXECUTE 'SELECT
>> INTO ...' for now. That's more than a tad annoying, because that leaves
>> no useful way to do a dynamically-built SELECT, but if we don't forbid
>> it I think we'll regret it later.
> You can always use CREATE TABLE AS.
Does SPI_exec() support that? (Tries it ... seems to work ...)
Cool. OK, we have the bases covered then; there's no need to allow
SELECT INTO inside EXECUTE until we can make it work as expected.
regards, tom lane