Re: Range Types, constructors, and the type system

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

In response to

Responses

Browse pgsql-hackers by date

  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?