RE: [SQL] Re: PL/pgsql EXECUTE 'SELECT INTO ...'

What I wrote wasn't about temp tables, it was about selecting into plpgsql
variables. It would appear that Jan's syntax gets around this problem.

MikeA

-----Original Message-----
From: Jan Wieck [mailto:janwieck(at)Yahoo(dot)com]
Sent: 08 February 2001 13:30
To: Tom Lane
Cc: Jan Wieck; pgsql-hackers(at)postgreSQL(dot)org; pgsql-sql(at)postgreSQL(dot)org
Subject: [SQL] Re: PL/pgsql EXECUTE 'SELECT INTO ...'

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

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
Nick West - Global Infrastructure Manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************