2015-10-20 17:15 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > Probably it was my request. I don't like to using NULL as value, that > should > > be ignored. The "hint" is clean, there NULL can be ignored, but what > about > > DETAIL or MESSAGE? > > If the field is required - as MESSAGE is - then its absence is an > error. If the field is optional, treat a NULL if the parameter were > not supplied. >
I understand well, what was proposed. Personally I see small risk, but I am thinking so can be useful if users can choose between two possibilities (strict, and NULL tolerant). For some adhoc work it can be useful. > > > I am strong in my opinion about PLpgSQL RAISE statement behave, but on > > second hand, proposed function should not be 100% same as RAISE stmt. > More > > we can simply add a parameter like "ignore_nulls" > > I would be willing to bet you a drink that 99.9% of people will want > the behavior Jim is advocating, so I don't think this should be > configurable. > 99.9% of people can think so it is good idea to the moment, when the important information will be lost without any hint, why it was lost. Default behave can be like Jim proposed. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
