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. 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! Pavel > > > Regards, > Jan > > -- > Jan Wieck > Senior Software Engineer > http://slony.info >
