pg...@j-davis.com (Jeff Davis) writes:
> On Fri, 2011-01-28 at 09:17 -0800, David Fetter wrote:
>> For consistency, and in order not to continue our atrocious naming
>> tradition, I'd like to propose that the above be named timestamprange
>> (tsrange for short) and timestamptzrange (tstzrange for short).
>
> No real objection, but I'd like to see if someone else will second it.
>
> Also, I don't think aliases are very easy to define. They appear to all
> be special cases in the backend code, without catalog support. Should I
> use domains? If not, I think we'll have to stick to one name.
Somehow, rangets, rangetstz seem better to me, but that's not a deep
issue. I'm not certain of the basis for *truly* preferring an ordering
of the components (ts/timestamp, tz, range). As long as it's rational,
and not too terribly inconsistent with other prefix/suffix handlings,
I'm fine with it.
Mind you, timestamptzrange seems a mite *long* to me.
>> > - INTRANGE (int4)
>>
>> int4range/intrange and the missing bigintrange/int8range
>
> I thought about adding int8range, and the first time around that's what
> I tried. But then I realized that the literal "4" is interpreted as an
> int4, meaning that "range(1,10)" would be interpreted as int4range, so
> int8range was slightly annoying to use because you have to cast the
> literals.
>
> Also, the storage is not particularly efficient right now anyway, so if
> you need int8range, you could probably use numrange instead.
>
> I don't mind either way. If you think someone will use it, I'll add it.
Making sure it's consistent with int4, int8, bigint sure seems like a
good idea.
>> Should there also be a timerange and a timetzrange?
>
> I thought about it, and I realized that I've never seen the "time" type
> used. Again, I'll add it if someone will use it.
>
> Keep in mind that it's fairly easy for people to add their own range
> types. The most difficult part is defining the "canonical" function if
> it is applicable, and the "subtype_float" function which is necessary
> for GiST.
I don't see much use for "time"; it is *so* likely that you'll need date
overlaps that it's difficult for it to be useful without making it
extremely magical (e.g. - stowing a lot of logic inside that adds in
date information behind the scenes).
FYI, it's compiling and testing fine for me. This one strikes me as an
exciting change, once GIST is in place. Well, actually, even without it :-).
postgres@localhost-> insert into foo (dr) values ('[2010-01-01,2011-12-31)');
INSERT 0 1
postgres@localhost-> select * from foo;
id | dr
----+----------------------------
1 | [ 2010-01-01, 2011-12-31 )
(1 row)
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/rdbms.html
If vegetarians eat vegetables, what do humanitarians eat?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
