2013/9/20 Robert Haas <robertmh...@gmail.com> > On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja <ma...@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. >
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 >
