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  (Marko Tiikkaja <marko@joh.to>)
Список 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 по дате отправления:

Предыдущее
От: Rajeev rastogi
Дата:
Сообщение: Re: PostgreSQL Service on Windows does not start if data directory given is relative path
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: Inheritance and indexes