Re: Range Types, constructors, and the type system

On Sat, Jun 25, 2011 at 6:29 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Different ranges over the same subtype make sense when using different
> total orders for the subtype. This is most apparent with text collation,
> but makes sense (at least mathematically, if not practically) for any
> subtype.
>
> For instance:
>  [a, Z)
> is a valid range in "en_US", but not in "C", so it makes sense to have
> multiple ranges over the same subtype with different collations.
>
> But what if you have a function (like a constructor), of the form:
>  (anyelement, anyelement) -> anyrange
> ? To work with the type system, you need to be able to figure out the
> return type from the arguments; which means to support functions like
> this we need a mapping from the subtype to the range type.
> Unfortunately, that restricts us to one range type per subtype (this
> isn't a problem for ARRAYs, because there is only one useful array type
> for a given element type).
>
> This problem first came up a while ago:
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg02788.php
>
> My workaround was to use domains, but that's not a very clean solution
> (you have to add a bunch of casts to make sure the right domain is
> chosen). It became entirely unworkable with collations, because people
> would be using different text collations a lot more frequently than,
> say, a different ordering for timestamptz. Tom mentioned that here:
>
> http://archives.postgresql.org/message-id/24831.1308579443@sss.pgh.pa.us
>
> I think Florian proposed the most promising line of attack here:
>
> http://archives.postgresql.org/message-id/AD4FC75D-DB99-48ED-9082-52EE3A4D74A6@phlo.org
>
> by suggesting that functions of the form:
>  (anyelement, [other non-anyrange arguments]) -> anyrange
> might be expendable. After all, they are only useful for constructors as
> far as we can tell. Other range functions will have an anyrange
> parameter, and we can use the actual type of the argument to know the
> range type (as well as the subtype).
>
> Although it's very nice to be able to say:
>  range(1,10)
> and get an int4range out of it, it's not the only way, and it's not
> without its problems anyway. For instance, to get an int8range you have
> to do:
>  range(1::int8, 10::int8)
> or similar.
>
> So, we could just make functions like:
>  int4range(int4, int4)
>  int8range(int8, int8)
>  ...
> when creating the range type, and it would actually be a usability
> improvement.

Couldn't we also do neither of these things? I mean, presumably
'[1,10]'::int8range had better work.

I'm not saying that's ideal from a usability perspective but I fear
this patch is going to be unmanageably large, and separating out the
things that you need for it to work at all from the things that you
need in order for it to be convenient might have some merit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company