From: | Scott Bailey <artacus(at)comcast(dot)net> |
---|---|
To: | |
Cc: | hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Range types |
Date: | 2009-12-16 22:15:29 |
Message-ID: | 4B295C01.3040803@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>> However, it does seem reasonable to allow people to restrict, either by
>> typmod or a check constraint the kinds of values that can be stored in
>> a particular column. Then an application can decide which way they want
>> their intervals to work and have the database enforce it.
>
> Sure --- the range datatype should absolutely provide inquiry functions
> that let you determine all the properties of a range, so something like
> "CHECK (is_open_on_right(col))" would work for that. I'm of the opinion
> that we must not usurp typmod for range behavior --- the right thing is
> to pass that through to the contained type, just as we do with arrays.
>
> (Note that a range over timestamp(0) would eliminate at least some of
> the platform dependencies we've been arguing about. I'm still quite
> dubious that "next timestamp" is anything except evidence that you've
> misformulated your problem, though.)
>
> regards, tom lane
Well our work is based on over 15 years of temporal research (not by us)
and numerous books from Snodgrass, Date and Celko; as well as partial
implementations in other databases. So its not like we took a blue pill
this weekend and woke up with this hair-brained idea.
I understand your concern. But I think the objections are based more on
implementation details with float timestamp rather than conceptually.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-12-16 22:18:41 | determine snapshot after obtaining locks for first statement |
Previous Message | Jeff Davis | 2009-12-16 22:14:40 | Re: Range types |