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
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 |
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 |