Re: Range Types, constructors, and the type system
От | Robert Haas |
---|---|
Тема | Re: Range Types, constructors, and the type system |
Дата | |
Msg-id | CA+Tgmoa93w=4cv3tHHZexprUFQyF1xs5WZdtJz_mEACBDCbbcg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Range Types, constructors, and the type system (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Range Types, constructors, and the type system
Re: Range Types, constructors, and the type system |
Список | pgsql-hackers |
On Tue, Jul 5, 2011 at 11:11 AM, Jeff Davis <pgsql@j-davis.com> wrote: > On Tue, 2011-07-05 at 10:06 -0400, Robert Haas wrote: >> > 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? > > It doesn't, it just avoids the need for an intermediate type. > > What I meant was that it might be strange to require a cast on the > result of a function call, because we don't really do that anywhere > else. Florian pointed out that it's common to require casting the > ARRAY[] constructor, so that has more of a precedent. I'm not really > sure how much that matters. > > I'm OK with the intermediate type, but Florian seems skeptical of that > idea. How about the idea of creating a family of four constructor functions for each new range type? The functions would be named after the range type, with "_cc", "_co", "_oc", and "_oo" appended. So, then, instead of writing: RANGE(1,8,'c','o')::int8range ...or somesuch, you could just say: int8range_co(1,8) ...which is both more compact and less ugly, IMHO, and seems to circumvent all the type system problems as well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: