Re: PL/pgSQL 1.2

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jan Wieck <jan(at)wi3ck(dot)info>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Bruce Momjian <bruce(at)momjian(dot)us>, Joel Jacobson <joel(at)trustly(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/pgSQL 1.2
Date: 2014-09-04 13:31:25
Message-ID: CAFj8pRDizHM1PdbTsOSxm04EzZWOicnES77Txb+_7-1fvGVzWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-09-04 15:24 GMT+02:00 Jan Wieck <jan(at)wi3ck(dot)info>:

> On 09/04/2014 01:14 AM, Pavel Stehule wrote:
>
>> 2014-09-03 23:19 GMT+02:00 Hannu Krosing <hannu(at)2ndquadrant(dot)com
>> A more SQL-ish way of doing the same could probably be called COMMAND
>> CONSTRAINTS
>> and look something like this
>>
>> SELECT
>> ...
>> CHECK (ROWCOUNT BETWEEN 0 AND 1);
>>
>>
>> It is very near to my proposed ASSERT
>>
>
> Only if the ASSERT syntax would become part of the original statement, it
> is supposed to check. In Hannu's command constraint example above, the
> statement that causes the error, and thus will be logged and become
> identified by the error message, is the actual SELECT (or other DML
> statement).
>

this is valid argument.

On second hand, I proposed a ASSERT that was not based on expressions only.
There is not a technical issue to write assert with knowledge of related
statement.

>
> I think I like the COMMAND CONSTRAINT the best so far.
>

I not, because when it will not be part of SQL, than parser in plpgsql will
be more complex. You have to inject SELECT, UPDATE, INSERT, DELETE

Pavel

>
>
> Regards,
> Jan
>
> --
> Jan Wieck
> Senior Software Engineer
> http://slony.info
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-04 13:37:12 Re: Escaping from blocked send() reprised.
Previous Message Michael Paquier 2014-09-04 13:29:06 Re: missing tab-completion for relation options