Skip site navigation (1) Skip section navigation (2)

Re: Range Types - typo + NULL string constructor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
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 14:41:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

> 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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Linas VirbalasDate: 2011-09-21 14:44:30
Subject: Hot Backup with rsync fails at pg_clog if under load
Previous:From: Heikki LinnakangasDate: 2011-09-21 14:31:11
Subject: Re: Inlining comparators as a performance optimisation

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group