Re: proposal: plpgsql - Assert statement

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Nov 23, 2014 at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

Two comments on that:

1. What is the likely use-case for such a thing (considering SQL is not
exactly friendly to pointers or reference types), and is it more
interesting than new statements that we are going to reject on the grounds
that we don't want to reserve any more plpgsql keywords?

2. The actual behavior would be the same as it would be for the case of
implicit-CALL that we discussed upthread. Namely, that it'd work just
fine as long as "foo" isn't any unreserved keyword. So the net effect
would be that plpgsql keywords would be sort of semi-reserved, much like
col_name_keywords in the core grammar: you can use 'em as variable names
but not necessarily as function names. With the current behavior where
they're fully reserved, you can't use them as either, not even where the
context is completely unambiguous. I have not heard anyone complaining
that col_name_keyword is a dumb idea and we should make all keywords fully
reserved.

regards, tom lane