On Mon, Mar 1, 2010 at 1:39 PM, Tom Lane <t...@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.o219m9lk016...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers