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 →
  1. Replace the "New Linear" GiST split algorithm for boxes and points with a

Attachments

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