I would think though that raising an exception is better than a default behavior which deletes data.
As an app dev I am quite used to all sorts of "APIs" throwing exceptions and have learned to deal with them.
This is my way of saying that raising an exception is an improvement over the current situation. May not be the "best" solution but definitely an improvement.
Thanks
Steve
On Sun, Oct 20, 2019 at 12:48 PM Andrew Dunstan <andrew.dunstan@xxxxxxxxxxxxxxx> wrote:
On 10/20/19 1:14 PM, David G. Johnston wrote:
> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan
> <andrew.dunstan@xxxxxxxxxxxxxxx
> <mailto:andrew.dunstan@xxxxxxxxxxxxxxx>> wrote:
>
> And yet another is to
> raise an exception, which is easy to write but really punts the issue
> back to the application programmer who will have to decide how to
> ensure
> they never pass in a NULL parameter.
>
>
> That's kinda the point - if they never pass NULL they won't encounter
> any problems but as soon as the data and their application don't see
> eye-to-eye the application developer has to decide what they want to
> do about it. We are in no position to decide for them and making it
> obvious they have a decision to make and implement here doesn't seem
> like a improper position to take.
The app dev can avoid this problem today by making sure they don't pass
a NULL as the value. Or they can use a wrapper function which does that
for them. So frankly this doesn't seem like much of an advance. And, as
has been noted, it's not consistent with what either MySQL or MSSQL do.
In general I'm not that keen on raising an exception for cases like this.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
