Re: Range Types - typo + NULL string constructor

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types - typo + NULL string constructor
Date: 2011-09-21 15:20:10
Message-ID: 6EA8A7F7-8DAF-4AC3-AB44-A1A97A9950F8@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sep21, 2011, at 16:41 , Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> On Sep21, 2011, at 14:00 , Robert Haas wrote:
>>> 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 ', '()').
>
> Keep in mind that the array I/O behavior is widely considered to suck.
> When we defined the record I/O behavior, we did not emulate that
> whitespace weirdness, nor a number of other weirdnesses. I would argue
> that ranges ought to model their I/O behavior on records not arrays,
> because that's not as much of a legacy syntax.

Interesting. Funnily enough, I always assumed it was the other way around.
Probably because I don't care much for the empty-unquoted-string-is-NULL
behaviour of records. But leaving that personal opinion aside, yeah, in that
case we should make range I/O follow record I/O.

>> 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.
>
> Right. In the record case, we used an empty string for NULL, and then
> had to insist on quotes for actual empty strings.

Hm, so we'd have

'(X,)' for range(X, NULL, '()'),
'(,X)' for range(NULL, X, '()') and
'(,)' for range(NULL, NULL, '()').

We'd then have the choice of either declaring

'(X,]' to mean '(X,)',
'[,X)' to mean '(,X)' and
'[,]' to mean '(,)'

or to forbid the use of '[' and ']' for unspecified bounds.

(Leaving out the ',' in the case of only one bound as in my reply to Robert's
mail somewhere else in this thread doesn't actually work, since it'd be
ambiguous whether '(X)' means range(X, NULL, '()') or range(NULL, X, '()').)

One nice property is that, apart from the different brackets used, this
representation is identical to the one used by records while still avoiding
the infinity vs. NULL confusion.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message YAMAMOTO Takashi 2011-09-21 15:22:40 BUG #6218: TRAP: FailedAssertion("!(owner->nsnapshots == 0)", File: "resowner.c", Line: 365)
Previous Message Andres Freund 2011-09-21 15:15:41 sequence locking