From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] string_to_array with empty input |
Date: | 2009-04-02 17:35:40 |
Message-ID: | 20090402173540.GP12225@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, Apr 02, 2009 at 09:29:04AM -0700, Steve Crawford wrote:
> Leif B. Kristensen wrote:
> >Somehow this reminds me of the old "division by zero" problem.
> >
> >IMO, the proper way to handle this kind of anomaly would be to test if
> >the length of the string is non-zero before submitting it to the
> >string_to_array() function.
>
> Quite the opposite. Where division by zero is simply illegal
This is just a matter of definitions; divide by zero is fine in lots of
languages and no exception will be raised. The fact that you're saying
it's "simply illegal" means that you've internalised the definition to
such an extent that any alternative appears "simply illegal".
It seems reasonable to assume that if, to pick an arbitrary choice,
string_to_array returned a zero element set people would say it was
"simply illegal" for it to do anything else. There are choices for
either and a choice needs to be made or the situation should somehow be
made impossible.
> I would argue against a change to have string_to_array('',',') throw an
> error.
I'd agree, throwing an exception here doesn't seem useful.
--
Sam http://samason.me.uk/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-04-02 17:41:21 | Re: [HACKERS] string_to_array with empty input |
Previous Message | Patrick Desjardins | 2009-04-02 17:34:41 | Re: [GENERAL] Re: [GENERAL] ERROR: XX001: could not read block 2354 of relation… |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-02 17:39:23 | Re: questions about not-null constraints and inheritance |
Previous Message | Simon Riggs | 2009-04-02 17:11:23 | Re: [COMMITTERS] pgsql: If we expect a hash join to be performed in multiple batches, |