Re: Assertions in PL/PgSQL

2013/9/20 Robert Haas <robertmhaas(at)gmail(dot)com>

> On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja <marko(at)joh(dot)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.
>

PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is not
too bad, and one new specialized statement doesn't kill us. A proposed
functionality is often used and we have not tools (macros) how to implement
it simply.

we support a conditions for few statement - so enhancing RAISE statement is
possible

so some form of RAISE EXCEPTION WHEN NOT FOUND AND use_assrts USING
message = 'there are no some';

but this form is relative long and less readable (can be difficult find
asserts in code and separate it from custom exceptions). I am fully for
some variant of ASSERT statement. The benefit is higher than cost.

ASSERT keyword is simply, readable - and I can accept it, if we found a
syntax for complete functionality (although I prefer a PRAGMA introduction).

Regards

Pavel

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