Re: plpgsql execute vs. SELECT ... INTO

Andrew Dunstan wrote:
> 
> 
> On 11/05/2010 06:54 PM, Tom Lane wrote:
> > Andrew Dunstan<andrew@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.")));

Can someone suggest updated hint text, like this?
 errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE AS instead.")));

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +