Re: PL/pgsql EXECUTE 'SELECT INTO ...'

From: Jan Wieck <janwieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org, pgsql-sql(at)postgreSQL(dot)org
Subject: Re: PL/pgsql EXECUTE 'SELECT INTO ...'
Date: 2001-02-08 13:29:49
Message-ID: 200102081329.IAA03675@jupiter.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

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've been
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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Ansley 2001-02-08 13:35:14 RE: [SQL] Re: PL/pgsql EXECUTE 'SELECT INTO ...'
Previous Message Jan Wieck 2001-02-08 12:22:13 Re: [HACKERS] Re: PL/PGSQL function with parameters

Browse pgsql-sql by date

  From Date Subject
Next Message Michael Ansley 2001-02-08 13:35:14 RE: [SQL] Re: PL/pgsql EXECUTE 'SELECT INTO ...'
Previous Message Jan Wieck 2001-02-08 12:22:13 Re: [HACKERS] Re: PL/PGSQL function with parameters