Re: plpgsql execute vs. SELECT ... INTO

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql execute vs. SELECT ... INTO
Date: 2010-11-05 22:59:41
Message-ID: 4CD48C5D.9080703@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/05/2010 06:54 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-05 23:20:52 Re: ALTER TABLE ... IF EXISTS feature?
Previous Message Tom Lane 2010-11-05 22:54:06 Re: plpgsql execute vs. SELECT ... INTO