Re: proposal: plpgsql - Assert statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: plpgsql - Assert statement
Дата
Msg-id 18442.1416439745@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal: plpgsql - Assert statement  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2014-11-19 23:54 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> The core of that complaint is that we'd have to make ASSERT a plpgsql
>> reserved word, which is true enough as things stand today.  However,
>> why is it that plpgsql statement-introducing keywords need to be
>> reserved?

> Doesn't it close a doors to implement a procedures call without explicit
> CALL statement (like PL/SQL) ?

So, in order to leave the door open for implicit CALL (which nobody's
ever proposed or tried to implement AFAIR), you're willing to see every
other proposal for new plpgsql statements go down the drain due to
objections to new reserved words?  I think your priorities are skewed.

(If we did want to allow implicit CALL, I suspect that things could be
hacked so that it worked for any function name that wasn't already an
unreserved keyword, anyway.  So you'd be no worse off.)

> Personally I doesn't feel to introduce lot of new keywords (statements) to
> plpgsql. Probably only two - ASSERT (assertions), PRAGMA (some cooperation
> with plpgsql extensions).

I can't say that either of those excite me particularly, so the idea
that those two are the only new statements we'd ever want to add seems
improbable.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Merging recovery.conf into PostgreSQL.conf -- where did this go?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: RLS with check option - surprised design