On Sep21, 2011, at 14:00 , Robert Haas wrote:
> On Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis <pg...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to