On Wed, 2011-09-21 at 10:41 -0400, Tom Lane wrote:
> Florian Pflug <fgp@phlo.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.
Done. Now range types more closely resemble records in parsing behavior.
Patch attached.
Changes:
* new parser + doc changes
* merged with master
* pg_dump now work
* various cleanup
TODO:
* ultimately, there should be a simple cache to avoid repeated syscache
lookups. I have put this off mainly to avoid premature optimization, but
that code has been pretty stable for a while
* support casts and typmod -- this requires the work for the
RangeCoerceExpr that I mentioned before
Regards,
Jeff Davis