Re: PL/pgSQL 1.2

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Joel Jacobson <joel(at)trustly(dot)com>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Bruce Momjian <bruce(at)momjian(dot)us>, 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 15:17:01
Message-ID: CAFj8pRDvivj8mChMa3BpaGifyecTjsW-=T5ELu3QoJ4FWdr-PA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-09-04 17:10 GMT+02:00 Joel Jacobson <joel(at)trustly(dot)com>:

>
>
> On 4 sep 2014, at 15:32, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>
>
>
> 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
>
>
> This is what I suspected. You are against the best syntax because they are
> more complex to implement. I think that's coming into the discussion from
> the wrong direction. First agree on the best syntax, then worry about the
> implementation.
>
>
Nobody say here, so it is best syntax. It is request of proprietary
enhancing of SQL and lot of people say strongly no. But you don't listen.

> I also understand the syntax changes will mean a lot of trouble for your
> plpgsql_check_function() project, but that cannot hold us back, we must aim
> for the best possible syntax with plpgsql2.
> Your work with plpgsql_check_function() btw saved me hundreds of hours of
> work, when we upgraded from 8.4 a few years ago, many thanks Pavel!
>

I have no problem with plpgsql_check_function management. I remember well
how issues is related to support plpgsql specific STRICT or INTO clauses.

Pavel

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-09-04 15:18:03 Re: PL/pgSQL 1.2
Previous Message Joel Jacobson 2014-09-04 15:16:25 Re: PL/pgSQL 1.2