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

From Tom Lane
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id 18442.1416439745@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: plpgsql - Assert statement  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2014-11-19 23:54 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> 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?

> Doesn't it close a doors to implement a procedures call without explicit
> CALL statement (like PL/SQL) ?

So, in order to leave the door open for implicit CALL (which nobody's
ever proposed or tried to implement AFAIR), you're willing to see every
other proposal for new plpgsql statements go down the drain due to
objections to new reserved words?  I think your priorities are skewed.

(If we did want to allow implicit CALL, I suspect that things could be
hacked so that it worked for any function name that wasn't already an
unreserved keyword, anyway.  So you'd be no worse off.)

> Personally I doesn't feel to introduce lot of new keywords (statements) to
> plpgsql. Probably only two - ASSERT (assertions), PRAGMA (some cooperation
> with plpgsql extensions).

I can't say that either of those excite me particularly, so the idea
that those two are the only new statements we'd ever want to add seems
improbable.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Merging recovery.conf into PostgreSQL.conf -- where did this go?
Next
From: Peter Geoghegan
Date:
Subject: Re: RLS with check option - surprised design