Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ?
От | Tom Lane |
---|---|
Тема | Make plpgsql throw error for SELECT ... INTO rowtypevar , ... ? |
Дата | |
Msg-id | 21116.1267468741@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Make plpgsql throw error for SELECT ... INTO rowtypevar
, ... ?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: