Skip site navigation (1) Skip section navigation (2)

Re: Range Types, constructors, and the type system

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Range Types, constructors, and the type system
Date: 2011-06-28 20:20:50
Message-ID: 610E50C6-1793-44C5-8EAB-54DE3F5D98D6@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun28, 2011, at 05:42 , Jeff Davis wrote:
> On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
>> Couldn't we also do neither of these things?  I mean, presumably
>> '[1,10]'::int8range had better work.
> 
> I think that if we combine this idea with Florian's "PAIR" suggestion
> here:
> http://archives.postgresql.org/message-id/AD4FC75D-DB99-48ED-9082-52EE3A4D74A6@phlo.org
> 
> then I think we have a solution.
> 
> If we add a type RANGEINPUT that is not a pseudotype, we can use that as
> an intermediate type that is returned by range constructors. Then, we
> add casts from RANGEINPUT to each range type. That would allow
>  range(1,2)::int8range
> to work without changing the type system around, because range() would
> have the signature:
>  range(ANYELEMENT, ANYELEMENT) -> RANGEINPUT
> and then the cast would change it into an int8range. But we only need
> the one cast per range type, and we can also support all of the other
> kinds of constructors like:
>  range_cc(ANYELEMENT, ANYELEMENT) -> RANGEINPUT
>  range_linf_c(ANYELEMENT) -> RANGEINPUT
> without additional hassle.

Hm, so RANGEINPUT would actually be what was previously discussed as
the "range as a pair of bounds" definition, as opposed to the
"range as a set of values" definition. So essentially we'd add a
second concept of what a "range" is to work around the range input
troubles.

I believe if we go that route we should make RANGEINPUT a full-blown
type, having "pair of bound" semantics. Adding a lobotomized version
just for the sake of range input feels a bit like a kludge to me.

Alternatively, we could replace RANGEINPUT simply with ANYARRAY,
and add functions ANYRANGE->ANYRANGE which allow specifying the
bound operator (<, <= respectively >,>=) after construction.

So you'd write (using the functions-as-fields syntax I believe
we support)
  (ARRAY[1,2]::int8range).left_open.right_closed for '(1,2]'
and
  ARRAY[NULL,2]::int8range for '[-inf,2]'

All assuming that modifying the type system to support polymorphic
type resolution based on the return type is out of the question... ;-)

best regards,
Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-06-28 20:23:51
Subject: Re: Fwd: Keywords in pg_hba.conf should be field-specific
Previous:From: Pavel StehuleDate: 2011-06-28 20:19:02
Subject: Re: Fwd: Keywords in pg_hba.conf should be field-specific

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group