Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error
От | Mor Lehr |
---|---|
Тема | Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error |
Дата | |
Msg-id | CALyvM2bE8j-E-dPRtXzpLXVccBFJn6F-GUhsJnaoFdRq_jU7UQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Missing semicolumn in anonymous plpgsql block does not raise syntax error
|
Список | pgsql-bugs |
How about inventing an opt-in strict mode
That can be useful at the session level, because we use anonymous blocks quite often.
I assume if such a setting existed - we would have used it in the original scenario.
Thanks again,
-Mor
On Mon, Jun 3, 2024 at 9:12 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
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 usefulBut 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 patterna := tab.a FROM tabinstead correcta := (SELECT tab.a FROM tab)orSELECT tab.a FROM tab INTO a;RegardsPavel--
Erik
В списке pgsql-bugs по дате отправления: