On 11/05/2010 06:54 PM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
The comment on the commit says:
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few weeks/months. This keeps our options
open for making it do the right plpgsql-ish thing in future without
creating a backwards compatibility problem. There is no loss of
functionality since people can get the same behavior with CREATE TABLE AS.
Do we really still need to keep out options open on this after all that
time?
I think it's still a good idea that it won't do something that is very
much different from what a non-EXECUTE'd SELECT INTO will do.
I forget, is there a HINT there suggesting CREATE TABLE AS? Maybe we
should add one if not.
No, (see below) we should certainly improve that and document the
behavior, if we're going to keep it.
if (*ptr == 'S' || *ptr == 's')
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("EXECUTE of SELECT ... INTO is not
implemented"),
errhint("You might want to use EXECUTE ...
INTO instead.")));
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
