Re: [HACKERS] string_to_array with empty input

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/

In response to

Browse pgsql-general by date

  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!

Browse pgsql-hackers by date

  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