Range types
in [PgSql]
|
Prev: Winflex
Next: [HACKERS] Fast or immediate shutdown
From: Jeff Davis on 14 Dec 2009 14:09 On Mon, 2009-12-14 at 13:32 -0500, Tom Lane wrote: > Well, if the intention is to invent two different kinds of ranges, with > different operators, for continuous and discrete data types, then fine. Originally I thought most of the use cases were workable as discrete ranges. If people want continuous ranges, that's certainly doable by using a slightly different API. > But the original post suggested no such thing, and provided (unworkable) > examples suggesting that the intent was to force every type to be > treated as discrete whether that makes any sense or not. I agree, we shouldn't say we support continuous types, but force them to be treated like discrete types. > The main question I would have is how to tell whether the underlying > type is really discrete. We can ask the user to provide a prior() and next() function, and if they aren't provided, we assume it's continuous. Also, this range mechanism may be useful to get the meaningful operators for a range type. For instance, for a range join (e.g. a temporal join), we could recognize the && as "overlaps" and then find the "strictly left of" operator if we wanted to do a range merge join. This might be cleaner than the previous idea to mark operator families as conforming to a certain convention for strategy numbers. > (Also, stuff like strings simply doesn't have any sane concept of a > unique next or previous value. I think the number of types that are > really discrete in this sense is very small, like maybe just ints and > enums.) I think "countable" is a more accurate word than "discrete". Strings are discrete but not countable. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Dec 2009 14:23 Jeff Davis <pgsql(a)j-davis.com> writes: > On Mon, 2009-12-14 at 13:32 -0500, Tom Lane wrote: >> The main question I would have is how to tell whether the underlying >> type is really discrete. > We can ask the user to provide a prior() and next() function, and if > they aren't provided, we assume it's continuous. Well, that still leaves us with the problem that Joe Schmo will file a bug when "create function next(float4) returns float4 as $$ select $1 + 0.00001 $$" doesn't behave sanely for him. I'd prefer not to leave it to the user to decide whether a type is discrete or not. The traffic on pgsql-bugs is convincing evidence that a very large fraction of our user-base doesn't understand that floats are inexact :-( > I think "countable" is a more accurate word than "discrete". Strings are > discrete but not countable. It's been too long since college math classes for me to be sure whether "discrete" is really the exact term here. But I'm even more suspicious of "countable". I think a suitable diagonalization argument might show that strings are countable. That's getting a bit off-topic though... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 14 Dec 2009 14:27 On Mon, 2009-12-14 at 11:10 -0800, Scott Bailey wrote: > I was referring to the syntax for how the user actually defined an enum > not about it's implementation. Basically what I was hoping to get out of > this thread was whether it was better to allow the user to define their > own range types by specifying the base type and possibly the granularity > and default inclusiveness of the end points, or if we should just > provide the types like period and intrange? To be a little bit more specific about the alternatives: 1. Make a contrib module that creates a variety of range types like PERIOD, PERIODTZ, INT4RANGE, NUMRANGE, etc. In order to support some of the other features I intend to work on, such as a range join (e.g. temporal join), we would need to mark an operator family to know that it conforms to a certain strategy number convention. See: http://archives.postgresql.org/pgsql-hackers/2009-10/msg01769.php http://archives.postgresql.org/pgsql-hackers/2009-10/msg01441.php 2. Implement some kind of ANYRANGE type and associated operators; and provide a way to define new range types by providing the base type, difference type (e.g. for TIMESTAMP, the difference type would be INTERVAL) and a couple support functions. This might be more flexible, and it would obviate the need for marking operator families. If the second approach seems promising, we can hammer out a real proposal and see if it's viable. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 14 Dec 2009 14:39 On Mon, Dec 14, 2009 at 2:23 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > It's been too long since college math classes for me to be sure whether > "discrete" is really the exact term here. But I'm even more suspicious > of "countable". I think a suitable diagonalization argument might show > that strings are countable. That's getting a bit off-topic though... It's actually a dovetailing argument, not a diagonalization argument, but yes, the set of strings is most certainly countable. ....Robert (former CS theory teaching assistant) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 14 Dec 2009 14:42
On Mon, 2009-12-14 at 14:23 -0500, Tom Lane wrote: > > We can ask the user to provide a prior() and next() function, and if > > they aren't provided, we assume it's continuous. > > Well, that still leaves us with the problem that Joe Schmo will file > a bug when "create function next(float4) returns float4 as > $$ select $1 + 0.00001 $$" doesn't behave sanely for him. I'd prefer > not to leave it to the user to decide whether a type is discrete or > not. The traffic on pgsql-bugs is convincing evidence that a very > large fraction of our user-base doesn't understand that floats are > inexact :-( I don't know how we can decide such a thing. Do you have any ideas? Perhaps we can compromise and restrict the support functions to C? That might be a high-enough wall, and of course it would keep non-superusers from confusing the underlying mechanism. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |