Обсуждение: plpgsql execute vs. SELECT ... INTO

Поиск
Список
Период
Сортировка

plpgsql execute vs. SELECT ... INTO

От
Andrew Dunstan
Дата:
(Prompted by a puzzled user on IRC)

Ten years ago, nearly, we made this commit 
<https://github.com/postgres/postgres/commit/8a2cdd77ad5c0a4f8902ea86d0377336e076abcb> 
(see what a good thing it is we carefully got all the history 
transferred to git?)

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-plpgsqlsemantics   as it was doing for the last few weeks/months.  This keeps our options   open for making it do
theright plpgsql-ish thing in future without   creating a backwards compatibility problem.  There is no loss of
functionalitysince 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?

cheers

andrew



Re: plpgsql execute vs. SELECT ... INTO

От
Tom Lane
Дата:
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.
        regards, tom lane


Re: plpgsql execute vs. SELECT ... INTO

От
Andrew Dunstan
Дата:

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


Re: plpgsql execute vs. SELECT ... INTO

От
Bruce Momjian
Дата:
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. +


Re: plpgsql execute vs. SELECT ... INTO

От
Bruce Momjian
Дата:
Bruce Momjian wrote:
> 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.")));

OK, suggested wording improvement applied with attached patch.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
new file mode 100644
index 689686b..88cb8eb
*** a/src/pl/plpgsql/src/pl_exec.c
--- b/src/pl/plpgsql/src/pl_exec.c
*************** exec_stmt_dynexecute(PLpgSQL_execstate *
*** 3249,3255 ****
                      ereport(ERROR,
                              (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                       errmsg("EXECUTE of SELECT ... INTO is not implemented"),
!                              errhint("You might want to use EXECUTE ... INTO instead.")));
                  break;
              }

--- 3249,3255 ----
                      ereport(ERROR,
                              (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                       errmsg("EXECUTE of SELECT ... INTO is not implemented"),
!                              errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS
instead.")));
                  break;
              }