On Sat, Sep 14, 2013 at 6:09 PM, Marko Tiikkaja <marko@joh.to> wrote:
> On 2013-09-14 23:55, Pavel Stehule wrote:
>> but introduction a reserved keword for one very special purpose (without
>> extensibility) is not prudent.
>
> How about using an existing keyword then? ASSERTION used to be reserved in
> the SQL standard but is unreserved in postgres. CHECK might work and is
> fully reserved. CONSTRAINT? IS?
Personally, I'm pretty skeptical about the value of adding dedicated
syntax for this. I mean, I'll be the first to admit that PL/pgsql is
a clunky and awkward language. But somebody's always proposing
something that they think will make it better, and I feel somehow that
if we accept all of those proposals at face value, we'll just end up
with a mess. So IMHO the bar for adding new syntax to PL/pgsql should
be reasonably high. YMMV, of course, and probably does.
The issue of how this is spelled is somewhat secondary for me. I
think ASSERT is probably as good as anything. But let's not kid
ourselves: even reserving this word only in PL/pgsql WILL break things
for some users, and there are LOTS of people out there with LOTS of
procedural code. Every tiny backward-incompatibility reduces by just
a little bit the percentage of those people who can upgrade and
increases the delay before they do. This is an area where past
experience has made me quite wary.
Maybe I'm worrying over nothing; this really is a pretty small change.But once bitten, twice shy.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company