From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(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-19 15:46:27 |
Message-ID: | 1316447187.7281.176.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Pirozzi | 2011-09-19 15:57:09 | Re: A little pg_dump patch |
Previous Message | Greg Sabino Mullane | 2011-09-19 15:44:13 | Re: A little pg_dump patch |