Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
От | Stephen Frost |
---|---|
Тема | Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns |
Дата | |
Msg-id | 20140118233743.GA31026@tamriel.snowman.net обсуждение исходный текст |
Ответ на | BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns (marko@joh.to) |
Список | pgsql-bugs |
* marko@joh.to (marko@joh.to) wrote: > I looked more closely into a gripe from Stephen Frost, which lead me into > discovering this behaviour: Well, as I got mentioned here.. The specific gripe I was bitching about on IRC goes thusly: =3D*# do $$ declare f1 int; declare f2 int; declare f3 int; begin select 1, 2, 3 into f1, f2 f3; end $$ language plpgsql; DO The issue above being that when you have a long list of columns being selected into variables, it can be easy to forget a comma and then debugging can be very painful. > Which directly contradicts this statement in the docs > (http://www.postgresql.org/docs/9.3/static/plpgsql-statements.html#PLPGSQ= L-STATEMENTS-SQL-ONEROW): >=20 > "If a row or a variable list is used as target, the query's result columns > must exactly match the structure of the target as to number and data type= s, > or else a run-time error occurs." Agreed. > This seems to have been broken by commit > 8bb3c8fe5413103c30ba8d1bcb3a1f8e46bddf3d. I strongly believe the > documentation is right in this case, and the behaviour ought to change. Yeah, I don't entirely follow the logic in that commit. It's strongly discouraged to use 'SELECT * INTO', for pretty obvious reasons. We certainly have no sympathy for users using 'SELECT *' from other languages when the columns get rearranged underneath them (due to a DROP COLUMN or similar). Thanks, Stephen
В списке pgsql-bugs по дате отправления: