Re: Singleton range constructors versus functional coercion notation

On Mon, Nov 21, 2011 at 9:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Nov 20, 2011, at 10:24 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>>> 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.
>
> But if you believe that, what syntax do you think people are likely to
> try if they want a singleton range constructor?  Leaving the user to
> discover the problem and try to invent a workaround is not better than
> doing it ourselves ...

Wait, do I hear the great Tom Lane arguing for putting more than the
minimal amount of stuff in core? :-)

I honestly don't know what function names people will pick, and I
don't care. Someone might like singleton(x), which would be
impractical as a built-in because there could be more than one range
type over the same base type, but if the user defines the function
they can pick what's convenient for them. If they use singletons
exceedingly frequently they might even want something really short,
like just(x) or s(x). Or they might say daterange1(x), along the
lines you suggested earlier. The point is that by not defining more
than necessary in core, we give the user the flexibility to do what
they want. In cases where that amounts to handing them a loaded gun
with the safety off, we shouldn't do it, but that doesn't seem to be
the case here. It doesn't take a lot of programming acumen to write a
function that passes two copies of its single argument to a built-in.
The only mistake anyone's likely to make is forgetting to declare it
non-VOLATILE.

But the real point is that I don't think we should assume that
singleton ranges are unique in being things for which people will want
shortcuts. We talked about having a behavior-changing GUC to control
whether the bounds are [) or [] or () or (], but we didn't do it,
because behavior-changing GUCs are a bad idea. But I fully expect
that people who make heavy use of range types will (and we should
encourage them to) define convenience functions with names of their
own choosing that pass the bounds that are useful to them. If isn't
the very model of a use-case for inline-able SQL functions, I'm not
sure what is.

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