Re: Singleton range constructors versus functional coercion notation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Singleton range constructors versus functional coercion notation
Date
Msg-id D813630D-9E74-442A-A470-86A9FD7ED4B1@gmail.com
Whole thread Raw
In response to Re: Singleton range constructors versus functional coercion notation  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Singleton range constructors versus functional coercion notation
List pgsql-hackers
On Nov 20, 2011, at 10:24 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Sat, 2011-11-19 at 15:57 -0500, Tom Lane wrote:
>>> I'm hesitant to remove them because the alternative is significantly
>>> more verbose:
>>>  numrange(1.0, 1.0, '[]');
>>
>> Right.  The question is, does the case occur in practice often enough
>> to justify a shorter notation?  I'm not sure.
>
> Well, if there were a good shorter notation, then probably so. But it
> doesn't look like we have a good idea, so I'm fine with dropping it.

We should also keep in mind that people who use range types can and likely will define their own convenience functions.
If people use singletons, or open ranges, or closed ranges, or one-hour timestamp ranges frequently, they can make
theirown notational shorthand with a 3-line CREATE FUNCTION statement.  We don't need to have it all in core. 

...Robert

pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Review for "Add permission check on SELECT INTO"
Next
From: Jan Kundrát
Date:
Subject: Re: [Review] Include detailed information about a row failing a CHECK constraint into the error message