Skip site navigation (1) Skip section navigation (2)

Re: Singleton range constructors versus functional coercion notation

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Singleton range constructors versus functional coercion notation
Date: 2011-11-22 07:49:49
Message-ID: CAEZATCWhPQDbs1KeAi-QBqD7Lo3FsZbigPOCdgZKfGany4Fzag@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 21 November 2011 14:55, 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 ...
>

In the field of mathematics, a standard shorthand notation for the
degenerate interval [x,x] is {x} - the singleton set - so that's one
possibility.

Dean

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-11-22 09:31:39
Subject: Re: VACUUM touching file but not updating relation
Previous:From: Kevin GrittnerDate: 2011-11-22 05:58:57
Subject: Re: explain analyze query execution time

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group