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

From Hannu Krosing
Subject Re: Assertions in PL/PgSQL
Date
Msg-id 523C4E26.2050908@2ndQuadrant.com
Whole thread Raw
In response to Re: Assertions in PL/PgSQL  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 09/20/2013 01:59 PM, Robert Haas wrote:
> 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.
>
Perhaps we could use the pragma approach here and add some types of new
functionality in omments

--#ASSERT .....

or even

--#pragma ASSERT .....

It is still not guaranteed to be 100% compatible, but at least changing
comments should be relatively safe way for fixing your functions

And you could have another pragma to disable some pragmas which you
could SET in GUC (global, session or per function) for extra ugliness ;)

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ




pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Assertions in PL/PgSQL
Next
From: Samrat Revagade
Date:
Subject: Re: Patch for fail-back without fresh backup