From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types, constructors, and the type system |
Date: | 2011-07-05 14:06:24 |
Message-ID: | CA+TgmoburoG8WdJGe5VXn-miZ-Lz1RsE6aA0rcUcWV3vj8fYNQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 1, 2011 at 2:09 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Thu, 2011-06-30 at 12:28 +0200, Florian Pflug wrote:
>> Well, arrays are containers, and we need two values to construct a range,
>
> What about empty ranges? What about infinite ranges?
>
> It seems quite a bit more awkward to shoehorn ranges into an array than
> to use a real type (even if it's intermediate and otherwise useless).
>
>> Hm, I guess. I'm sill no huge fan of RANGEINPUT, but if we prevent
>> it from being used as a column type and from being used as an argument
>> type, then I guess it's workable...
>>
>> Btw, what happened to the idea of making RANGE(...) a special syntactic
>> construct instead of a normal function call? Did we discard that for its
>> intrusiveness, or were there other reasons?
>
> It has not been discarded; as far as I'm concerned it's still on the
> table. The main advantage is that it doesn't require an intermediate
> type, and that requiring a cast (or some specification of the range
> type) might be a little more natural. The downside is that, well, it's
> new syntax, and there's a little inertia there.
>
> But if it's actually better, we should do it. If an intermediate type
> seems to be problematic, or if people think it's strange to require
> casting, then I think this is reasonable.
I don't understand how the bespoke syntax avoids the need for a cast?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-05 14:09:47 | Re: Libpq enhancement |
Previous Message | Robert Haas | 2011-07-05 14:02:17 | Re: Bug in SQL/MED? |