Re: Range Types - typo + NULL string constructor
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Florian Pflug <fgp@phlo.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-10-02T19:05:31Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Replace the "New Linear" GiST split algorithm for boxes and points with a
- 7f3bd86843e5 9.2.0 cited
Attachments
- rangetypes-20111002.gz (application/x-gzip)
On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote: > Looking at the patch, I noticed that it's possible to specify the default > boundaries ([], [), (] or ()) per individual float type with the > DEFAULT_FLAGS clause of CREATE TYPE .. AS RANGE. I wonder if that doesn't > do more harm then good - it makes it impossible to deduce the meaning of > e.g. numericrange(1.0, 2.0) without looking up the definition of numericrange. > > I suggest we pick one set of default boundaries, ideally '[)' since that > is what all the built-in canonization functions produce, and stick with it. Done. Also, made the range parsing even more like records with more code copied verbatim. And fixed some parsing tests along the way. Regards, Jeff Davis