Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id 17439.1416437695@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Marko Tiikkaja <marko@joh.to>)
Responses Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: plpgsql - Assert statement  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Add shutdown_at_recovery_target option to recovery.conf
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql - Assert statement