From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Singleton range constructors versus functional coercion notation |
Date: | 2011-11-21 13:18:19 |
Message-ID: | D813630D-9E74-442A-A470-86A9FD7ED4B1@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Nov 20, 2011, at 10:24 PM, Jeff Davis <pgsql(at)j-davis(dot)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 their own notational shorthand with a 3-line CREATE FUNCTION statement. We don't need to have it all in core.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Kundrát | 2011-11-21 13:59:59 | Re: [Review] Include detailed information about a row failing a CHECK constraint into the error message |
Previous Message | Albe Laurenz | 2011-11-21 11:38:59 | Re: Review for "Add permission check on SELECT INTO" |