Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error
Дата
Msg-id CAFj8pRDm=bqd7HBbi9omLxjvC+DLKezrZooQs=96GGsCxRdiYg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error  (Erik Wienhold <ewie@ewie.name>)
Ответы Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error
Список pgsql-bugs


po 3. 6. 2024 v 18:46 odesílatel Erik Wienhold <ewie@ewie.name> napsal:
On 2024-06-03 00:18 +0200, Tom Lane wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > I think you just wrote the equivalent of:
> > l_cnt := (select 1 as delete from foo3 where id=1);
> > Which is a valid query.
>
> Still another example of the folly of letting AS be optional.
> I don't suppose we can ever undo that though.

How about inventing an opt-in strict mode (like in Perl or JavaScript)
that prevents certain footguns?  For example, disallowing bare column
labels.

That could be enabled for the current session or transaction:

    SET strict_parsing = { on | off };

Or just for individual routines:

    CREATE PROCEDURE myproc()
        SET strict_parsing = { on | off }
        LANGUAGE plpgsql ...


Probably it is not bad idea - it can be generally useful

But I think it is better to introduce a new entry for plpgsql expressions in gram.y.

Unfortunately it is not a compatible change. Years ago was popular to use a pattern

a := tab.a FROM tab

instead correct

a := (SELECT tab.a FROM tab)

or

SELECT tab.a FROM tab INTO a;

Regards

Pavel

 
--
Erik


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Alejandro Burne
Дата:
Сообщение: Visibility of a local variable
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #18492: Adding a toasted column to a table with an inherited temp table fails with Assert