Re: Proposal for Allow postgresql.conf values to be changed via SQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal for Allow postgresql.conf values to be changed via SQL
Дата
Msg-id 22694.1354305573@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Proposal for Allow postgresql.conf values to be changed via SQL  (Amit Kapila <amit.kapila@huawei.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 28, 2012 at 9:47 AM, Amit kapila <amit.kapila@huawei.com> wrote:
>> 5. PERSISTENT Keyword is added to the reserved keyword list. As it was giving some errors given below while parsing
gram.y
>> 15 shift/reduce conflicts .

> Allow me to be the first to say that any syntax for this feature that
> involves reserving new keywords is a bad syntax.

Let me put that a little more strongly: syntax that requires reserving
words that aren't reserved in the SQL standard is unacceptable.

Even if the new word is reserved according to SQL, we'll frequently
try pretty hard to avoid making it reserved in Postgres, so as not to
break existing applications.  But if it's not in the standard then
you're breaking applications that can reasonably expect not to get
broken.

But having said that, it's not apparent to me why inventing SET
PERSISTENT should require reserving PERSISTENT.  In the existing
syntaxes SET LOCAL and SET SESSION, there's not been a need to
reserve LOCAL or SESSION.  Maybe you're just trying to be a bit
too cute in the grammar productions?  Frequently there's more than
one way to do it and not all require the same level of keyword
reservedness.
        regards, tom lane



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: initdb.c::main() too large
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Enabling frontend-only xlog "desc" routines