Re: Range Types, constructors, and the type system
От | Merlin Moncure |
---|---|
Тема | Re: Range Types, constructors, and the type system |
Дата | |
Msg-id | CAHyXU0zw6x2a_FqwQc80a_StwrjVTkyxbqDDhMX8MpzjcUce_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Range Types, constructors, and the type system (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Range Types, constructors, and the type system
|
Список | pgsql-hackers |
On Tue, Jul 5, 2011 at 10:26 AM, Robert Haas <robertmhaas@gmail.com> wrote: > 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. +1 on this (so you wouldn't even then directly cast to a range?) merlin
В списке pgsql-hackers по дате отправления: