Re: Assertions in PL/PgSQL
От | Robert Haas |
---|---|
Тема | Re: Assertions in PL/PgSQL |
Дата | |
Msg-id | CA+Tgmoa64f2src+Mfq2+MsJn_S2wG9nLvmbY=wBkP8hp0c+-7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertions in PL/PgSQL (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: Assertions in PL/PgSQL
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: Assertions in PL/PgSQL (Hannu Krosing <hannu@2ndQuadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: