Re: Range Types - typo + NULL string constructor - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Range Types - typo + NULL string constructor
Date
Msg-id EB0F4C9B-E674-4F9E-8E89-15BAF4D5F4B7@phlo.org
Whole thread Raw
In response to Re: Range Types - typo + NULL string constructor  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Range Types - typo + NULL string constructor
Re: Range Types - typo + NULL string constructor
List pgsql-hackers
On Sep21, 2011, at 14:00 , Robert Haas wrote:
> On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>> On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote:
>>> (I am also vaguely wondering what happens if if you have a text
>>> range.... is (nubile, null) ambiguous?)
>> 
>> There are a few ways to handle that. I would lean toward parsing the
>> NULL as a special keyword, and then rejecting it (does it matter if it's
>> upper case?).
> 
> Boy, that seems really weird to me.  If you're going to do it, it
> ought to be case-insensitive, but I think detecting the case only for
> the purpose of rejecting it is probably a mistake.  I mean, if
> (nubile, nutty) is OK, then (nubile, null) and (null, nutty) don't
> really seem like they ought to be any different.

But that's exactly how arrays behave too. '{null,nutty}' is interpreted
as ARRAY[NULL,'nutty'] while '{nubile,nutty}' is interpreted as
ARRAY['nubile','nutty'].

> Otherwise, anyone
> who wants to construct these strings programatically is going to need
> to escape everything and always write ("cat","dog") or however you do
> that, and that seems like an unnecessary imposition.

Unless you fully depart from what arrays you, you'll have to do that anyway
because leading and trailing spaces aren't considered to be significant in
non-quoted elements. In other words, '( cat , dog )' represents
textrange('cat', 'dog', '()'), *not* textrange(' cat ', ' dog ', '()').

Also, as long as we need to recognize at least one special value meaning
a non-existing bound ('INF' or 'Infinity' or whatever), I don't see a way
around the need for quotes in the general case. Well, expect making the
representation of
 range(X, NULL, '[)') be '[X)',

the one of
 range(NULL, X, '(]') be '(X]'

and the one of
 range(NULL, NULL, '()') be '()',

but I'm not sure that's an improvement. And even if it was, you'd still
need to quote X if it contained one of "(",")","[","]" or ",". So most
client would probably still choose to quote unconditionally, instead of
detecting whether it was necessary or not.

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Shared sequence-like objects in PostgreSQL
Next
From: Robert Haas
Date:
Subject: Re: Range Types - typo + NULL string constructor