2014-09-04 17:10 GMT+02:00 Joel Jacobson <j...@trustly.com>: > > > On 4 sep 2014, at 15:32, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > > > 2014-09-04 15:24 GMT+02:00 Jan Wieck <j...@wi3ck.info>: > >> On 09/04/2014 01:14 AM, Pavel Stehule wrote: >> >>> 2014-09-03 23:19 GMT+02:00 Hannu Krosing <ha...@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 >> > >
