Re: plpgsql execute vs. SELECT ... INTO

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.")));



cheers

andrew