Tom,
> 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
<snip>
> (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().)
All of this sounds good, but as a *heavy* PL/pgSQL user,
it's still going off on somewhat of a tangent. As far as
I'm concerned, the EXECUTE method was just a workaround for
the lack "object" variables. What I always would rather
have had is simply being able to drop a variable ... or an
OID ... into a SELECT statement and not bothering with
EXECUTE at all.
> This does not look like something to be tackling when
> we're already
> in late beta, unfortunately.
I'd agree with that. :-)
> 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.
Unfortunately, I have already used EXECUTE in several
functions ... my search routines will be hard to run without
it. Perhaps you could turn off EXECUTE by default, but
allow it as a compile-time option for those of us wise
enough to understand the dangers?
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________ Complete information technology josh@agliodbs.com and
datamanagement solutions (415) 565-7293 for law firms, small businesses fax 621-2533 and non-profit
organizations. San Francisco
