Re: proposal: plpgsql - Assert statement

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: plpgsql - Assert statement
Дата
Msg-id 17439.1416437695@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: plpgsql - Assert statement  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: plpgsql - Assert statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Marko Tiikkaja <marko@joh.to> writes:
> I also went back to the original thread, and I think Heikki's summary 
> dismissed e.g. Robert's criticism quite lightly: 
> http://www.postgresql.org/message-id/CA+TgmobWoSSRNcV_iJK3xhsytXb7Dv0AWGvWkMEurNTOVEZYyw@mail.gmail.com

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?  The only reason for that AFAICS is to allow us to distinguish
the statements from assignments.  But it seems like that could possibly
be gotten around with some work.  The first thing that comes to mind is
for the lexer to do one-token lookahead and assume that the second
token of an assignment must be ":=" (aka "="), ".", or "[".  (Have
I missed any cases?)  Then, any statement for which the second token
can't be one of those, which is surely most if not all of them, could
have an unreserved leading keyword.  This would at a stroke dereserve
about half of plpgsql's existing reserved words, as well as remove a
roadblock for ASSERT and other new statements.
        regards, tom lane



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Add shutdown_at_recovery_target option to recovery.conf
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: plpgsql - Assert statement