From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] string_to_array with empty input |
Date: | 2009-04-01 19:17:50 |
Message-ID: | 20090401191750.GG12225@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, Apr 01, 2009 at 07:40:16PM +0100, Greg Stark wrote:
> The existing behaviour of returning NULL is the only "consistent"
> choice since the correct value is "unknown". And one could argue that
> it's easier to replace NULL with the correct value if the programmer
> knows using coalesce than it is to replace either "" or {""}.
Couldn't a similar argument be applied for division by zero? Since it's
not known whether the user wants to get a "divide by zero" exception or
"infinity" PG should return NULL and punt the choice to the user.
I think everybody would agree that this would be a bad thing to do!
> But I'm
> still leaning to thinking that using an arbitrary choice that at least
> gets most users intentions is better.
I'd agree; returning NULL and not forcing the user to make a choice
is a bad design decision---the user doesn't need to put a coalesce
in and hence their code will probably break in strange ways when
they're not expecting it. Nobody suggest adding a third parameter to
string_to_array, please!
The general mantra that seems to apply here is "one good option is
better than two bad ones".
--
Sam http://samason.me.uk/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-04-01 19:19:23 | Re: [HACKERS] string_to_array with empty input |
Previous Message | Jennifer Trey | 2009-04-01 19:16:49 | Installed PG with pgAdmin, some days later, now my password don't work! |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-04-01 19:19:23 | Re: [HACKERS] string_to_array with empty input |
Previous Message | Hiroshi Inoue | 2009-04-01 18:57:42 | Re: More message encoding woes |