Re: PL/pgsql EXECUTE 'SELECT INTO ...'
От | Jan Wieck |
---|---|
Тема | Re: PL/pgsql EXECUTE 'SELECT INTO ...' |
Дата | |
Msg-id | 200102081329.IAA03675@jupiter.greatbridge.com обсуждение исходный текст |
Ответ на | PL/pgsql EXECUTE 'SELECT INTO ...' (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: PL/pgsql EXECUTE 'SELECT INTO ...'
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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'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
В списке pgsql-sql по дате отправления: