On 3/25/15 1:21 AM, Pavel Stehule wrote:
2015-03-25 0:17 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us
<mailto:t...@sss.pgh.pa.us>>:
Pavel Stehule <pavel.steh...@gmail.com
<mailto:pavel.steh...@gmail.com>> writes:
> updated version with Jim Nasby's doc and rebase against last changes in
> plpgsql.
I started looking at this patch. ISTM there are some pretty
questionable
design decisions in it:
1. Why create a core GUC to control a behavior that's plpgsql-only?
I think it'd make more sense for this to be a plgsql custom GUC
(ie, "plpgsql.enable_asserts" or some such name).
This type of assertations can be implemented in any PL language - so I
prefer global setting. But I have not strong option in this case - this
is question about granularity - and more ways are valid.
+1
2. I find the use of errdetail to report whether the assertion condition
evaluated to FALSE or to NULL to be pretty useless. (BTW, is
considering
NULL to be a failure the right thing? SQL CHECK conditions consider
NULL
to be allowed ...)
This is a question - I am happy with SQL CHECK for data, but I am not
sure if same behave is safe for plpgsql (procedural) assert. More
stricter behave is safer - and some bugs in procedures are based on
unhandled NULLs in variables. So in this topic I prefer implemented
behave. It is some like:
+1. I think POLA here is that an assert must be true and only true to be
valid. If someone was unhappy with that they could always coalesce(...,
true).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
