Re: PL/pgSQL 1.2 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: PL/pgSQL 1.2
Date
Msg-id CAFj8pRDvivj8mChMa3BpaGifyecTjsW-=T5ELu3QoJ4FWdr-PA@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL 1.2  (Joel Jacobson <joel@trustly.com>)
List pgsql-hackers



2014-09-04 17:10 GMT+02:00 Joel Jacobson <joel@trustly.com>:


On 4 sep 2014, at 15:32, Pavel Stehule <pavel.stehule@gmail.com> wrote:




2014-09-04 15:24 GMT+02:00 Jan Wieck <jan@wi3ck.info>:
On 09/04/2014 01:14 AM, Pavel Stehule wrote:
2014-09-03 23:19 GMT+02:00 Hannu Krosing <hannu@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL 1.2
Next
From: Joel Jacobson
Date:
Subject: Re: PL/pgSQL 1.2