Re: Range Types - typo + NULL string constructor

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Florian Pflug <fgp@phlo.org>, Erik Rijkers <er@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2011-09-21T12:00:26Z
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 Wed, Sep 21, 2011 at 3:29 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Mon, 2011-09-19 at 12:26 -0400, Robert Haas wrote:
>> What I really
>> care about is that we don't talk ourselves into needing a zillion
>> constructor functions.  Making things work with a single constructor
>> function seems to me to simplify life quite a bit, and allowing there
>> seems essential for that.
>
> I think we pretty much all agree on that. However, you did see the note
> about the difficulty of using default parameters in built-in functions,
> right?
>
> I ultimately ended up with 4 constructors, each with the same name but
> 0, 1, 2, and 3 parameters. Suggestions welcome.
>
>> (I am also vaguely wondering what happens if if you have a text
>> range.... is (nubile, null) ambiguous?)
>
> There are a few ways to handle that. I would lean toward parsing the
> NULL as a special keyword, and then rejecting it (does it matter if it's
> upper case?).

Boy, that seems really weird to me.  If you're going to do it, it
ought to be case-insensitive, but I think detecting the case only for
the purpose of rejecting it is probably a mistake.  I mean, if
(nubile, nutty) is OK, then (nubile, null) and (null, nutty) don't
really seem like they ought to be any different.  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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company