From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Type constructors |
Date: | 2011-02-10 18:46:20 |
Message-ID: | AANLkTindggjTFz8pt9ddNnrvatrXHRjFzKwq_20p1KPG@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 10, 2011 at 1:41 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> This might solve the constructor problem nicely if we could do things
> like:
> RANGE[10,20)
> But I have a feeling that will either cause a bizarre problem with the
> grammar, or someone will think it's not very SQL-like.
I think won't cause any problem at all if RANGE is fully reserved, but
like you say we probably don't want to do that unless it's absolutely
necessary, and if you don't actually need to be able to type in foo
RANGE JOIN bar then it probably isn't.
I think your proposed naming schema for constructors is pretty
reasonable, except I might use "o" for open and "c" for closed rather
than "i" and "_", i.e. range_oo(), range_oc(), range_co(), range_cc().
If that'll get us by without fully reserving RANGE then I'd certainly
be in favor of doing it that way. I was just saying - if we were
inevitably going to have to reserve RANGE, then we could try to
squeeze a little more out of it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-02-10 18:52:19 | Re: ALTER EXTENSION UPGRADE, v3 |
Previous Message | Jeff Davis | 2011-02-10 18:41:07 | Re: Range Type constructors |