Thread: Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?

Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?

From
Tom Lane
Date:
Anybody have an opinion about whether to try to improve the error
response exhibited in bug #5352?
http://archives.postgresql.org/message-id/201003010922.o219M9lk016559@wwwmaster.postgresql.org

Currently, if the first variable named after INTO is a rowtype variable,
we just stop parsing the INTO clause right there.  Bug #5352 is not the
first case we've seen of people expecting to be able to write additional
INTO targets after that.  While I'm not interested right now in trying
to define or implement what it would mean to do that, it would be a
pretty trivial change to look ahead for a comma, and if one is seen to
throw an error along the line of "INTO can have only one target variable
if the target is a row or record variable".

It seems just barely possible that this could break functions that work
now, in which the INTO clause is located just ahead of a comma that does
actually belong to the surrounding SELECT's syntax.  However the user
could always work around it by relocating the INTO clause to someplace
else --- like say the places that we recommend putting INTO.

Aside from giving a less confusing message, making this change would
help to forestall future compatibility problems when and if we do
generalize INTO to accept multiple targets in such cases.  If we've been
throwing an error for that syntax for a release or three, it'll be much
less likely to bite people in the rear when it suddenly starts doing
something different.

So I'm inclined to make the change, but only in HEAD --- if there is
anyone whose function gets broken, they'd want to see that happen in
a major release not a minor update.

Comments?
        regards, tom lane


Re: Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?

From
Robert Haas
Date:
On Mon, Mar 1, 2010 at 1:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Anybody have an opinion about whether to try to improve the error
> response exhibited in bug #5352?
> http://archives.postgresql.org/message-id/201003010922.o219M9lk016559@wwwmaster.postgresql.org
>
> Currently, if the first variable named after INTO is a rowtype variable,
> we just stop parsing the INTO clause right there.  Bug #5352 is not the
> first case we've seen of people expecting to be able to write additional
> INTO targets after that.  While I'm not interested right now in trying
> to define or implement what it would mean to do that, it would be a
> pretty trivial change to look ahead for a comma, and if one is seen to
> throw an error along the line of "INTO can have only one target variable
> if the target is a row or record variable".
>
> It seems just barely possible that this could break functions that work
> now, in which the INTO clause is located just ahead of a comma that does
> actually belong to the surrounding SELECT's syntax.  However the user
> could always work around it by relocating the INTO clause to someplace
> else --- like say the places that we recommend putting INTO.
>
> Aside from giving a less confusing message, making this change would
> help to forestall future compatibility problems when and if we do
> generalize INTO to accept multiple targets in such cases.  If we've been
> throwing an error for that syntax for a release or three, it'll be much
> less likely to bite people in the rear when it suddenly starts doing
> something different.
>
> So I'm inclined to make the change, but only in HEAD --- if there is
> anyone whose function gets broken, they'd want to see that happen in
> a major release not a minor update.
>
> Comments?

It seems like a reasonable thing to do, I guess.  The whole idea that
INTO can be placed absolutely anywhere is really pretty strange, and
this is only chipping away at the edges of the weirdness.

portal=# create or replace function f() returns integer as $$declare x
record; begin select 1 into x + 1 as v; return x.v; end $$ language
plpgsql;
CREATE FUNCTION
portal=# select f();f
---2
(1 row)

...Robert