Re: proposal: plpgsql - Assert statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-11-19 22:54:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Marko Tiikkaja <marko(at)joh(dot)to> writes:
> I also went back to the original thread, and I think Heikki's summary
> dismissed e.g. Robert's criticism quite lightly:

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-11-19 22:55:10 Re: proposal: plpgsql - Assert statement
Previous Message Petr Jelinek 2014-11-19 22:47:09 Re: Add shutdown_at_recovery_target option to recovery.conf