On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> 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.
>
> Attached is a draft patch that de-reserves 17 of plpgsql's existing
> reserved words, leaving 24 still reserved (of which only 9 are not also
> reserved in the core grammar). This would make it painless to invent an
> ASSERT statement, as well as any other new statement type that's not
> associated with looping or block structure. (The limiting factor on those
> is that if a statement could have an opt_block_label, its keyword still
> has to be reserved, unless we want to complicate matters a bunch more.)
I like the idea of making these keywords less-reserved, but I'm
wondering how future-proof it is. It seems to rely heavily on the
fact that the syntax for lvalues is extremely restricted. Allowing
foo(bar) as an lvalue, for example, would pretty much require
completely reverting this, AFAICS, as would any other type of lvalue
that needs more than one token of lookahead to identify. How sure are
we that we're never going to want to do something like that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company