PL/pgsql EXECUTE 'SELECT INTO ...'
От | Tom Lane |
---|---|
Тема | PL/pgsql EXECUTE 'SELECT INTO ...' |
Дата | |
Msg-id | 10497.981602102@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: PL/pgsql EXECUTE 'SELECT INTO ...'
Re: PL/pgsql EXECUTE 'SELECT INTO ...' Re: PL/pgsql EXECUTE 'SELECT INTO ...' |
Список | pgsql-hackers |
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. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: