Re: plpgsql.consistent_into
От | Marti Raudsepp |
---|---|
Тема | Re: plpgsql.consistent_into |
Дата | |
Msg-id | CABRT9RCP=HWLmiAR6xhb1h-gOPZudihnkcLKfbVNyzupM1rpYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsql.consistent_into (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: plpgsql.consistent_into
|
Список | pgsql-hackers |
I've always hated INTO in procedures since it makes the code harder to follow and has very different behavior on the SQL level, in addition to the multi-row problem you bring up. If we can make assignment syntax more versatile and eventually replace INTO, then that solves multiple problems in the language without breaking backwards compatibility. On Tue, Jan 14, 2014 at 4:30 AM, Marko Tiikkaja <marko@joh.to> wrote: > On 2014-01-14 02:54, Marti Raudsepp wrote: >> But PL/pgSQL already has an assignment syntax with the behavior you want: > > According to the docs, that doesn't set FOUND which would make this a pain > to deal with.. Right you are. If we can extend the syntax then we could make it such that "= SELECT" sets FOUND and other diagnostics, and a simple assignment doesn't. Which makes sense IMO: a = 10; -- simple assignments really shouldn't affect FOUND With explicit SELECT, clearly the intent is to perform a query: a = SELECT foo FROM table; And this could also work: a = INSERT INTO table (foo) VALUES (10) RETURNING foo_id; AFAICT the fact that this works is more of an accident and should be discouraged. We can leave it as is for compatibility's sake: a = foo FROM table; Now, another question is whether it's possible to make the syntax work. Is this an assignment from the result of a subquery, or is it a query by itself? a = (SELECT foo FROM table); Does anyone consider this proposal workable? Regards, Marti
В списке pgsql-hackers по дате отправления: