Re: Assertions in PL/PgSQL - Mailing list pgsql-hackers

On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja <marko@joh.to> wrote:
>> 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.
>
> The thing is, what this means is that to add a new feature to the language,
> you have to make the syntax so damn ugly that no one wants to use it (see
> row_count, for example) or you will break some poor user's function.  And
> now we got all this cool functionality which nobody wants to use, and the
> language itself actually gets progressively worse.  All this is starting to
> sound like it's already too late to make PL/PgSQL better, and we should just
> start afresh.

To some extent I agree that PL/pgsql is hopeless.  I think there are
some things we can do to improve it, but most of what gets proposed at
least in this forum strikes me as tinkering around the edges, and it
can't make up for fundamentally bad language design decisions.  Part
of the problem, of course, is that most programming languages don't
get re-released every year.  It's not that it would be OK for C to
suddenly reserve a bunch of new keywords; it's that they don't try.
And when they do release no language versions (like C99) some people
(like us) don't adopt them, for fear of being unable to run our code
on older systems.  Such considerations apply with equal force to
PL/pgsql, but it gets a new release every year rather than every
decade, so the problems are magnified.

The other part of the problem is that the language isn't designed from
the beginning to be extensible.  In Perl, for example, they chose to
mark variables with a leading $, @, or % and functions with a leading
&.  That last marking has largely fallen into desuetude, but the point
is that - to the extent that you do have and use such markers - you
can add new keywords without breaking anything.  Some languages can
also distinguish keywords positionally; for example, ABORT doesn't
need to be reserved in PostgreSQL's SQL dialect because it can only
appear as a command at the beginning of a line, and it can't be a
column, type, or function name in that position.  Such an approach
might even work ASSERT in PL/pgsql, if there's a clean way to
disambiguate vs. the assignment syntax.  But even if we can make that
work, we're going to continue to face this problem with each new
language extension.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company