Horton

Re: Range Types - typo + NULL string constructor

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Florian Pflug <fgp@phlo.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-09-19T15:46:27Z
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

On Mon, 2011-09-19 at 17:23 +0200, Florian Pflug wrote:
> The one reason I can see in favour of supporting N-U-L-L there is 
> compatibility with arrays.

But arrays actually do store and produce NULLs; ranges don't.

>  I've recently had the questionable pleasure
> of writing PHP functions to parse and emit our textual representations of
> arrays, records, dates and timestamps. After that experience, I feel that
> the number of similar-yet-slightly-different textual input output format
> for non-primitive types is already excessive, and any further additions
> should be modeled after some existing ones.

I'm not clear on how accepting "NULL" would really save effort. With
ranges, the brackets have an actual meaning (inclusivity), and empty
ranges have no brackets at all. So I don't think it's going to be easy
to write one function to parse everything.

What about binary formats?

Regards,
	Jeff Davis