Re: Range Types, constructors, and the type system - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Range Types, constructors, and the type system
Date
Msg-id 1309969333.3012.114.camel@jdavis
Whole thread Raw
In response to Re: Range Types, constructors, and the type system  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Range Types, constructors, and the type system
List pgsql-hackers
On Wed, 2011-07-06 at 09:10 -0400, Robert Haas wrote:
> > There's some slight ugliness around the NULL/infinity business, but I
> > think that I could be convinced. I'd like to avoid confusion between
> > NULL and infinity if possible.
> 
> I was thinking that if you passed 'i' for one of the bounds, it would
> ignore the supplied argument and substitute its special infinity
> value.  But you'd still need to supply some argument in that position,
> which could be NULL or anything else.  It doesn't really seem worth
> having additional constructor functions to handle the case where one
> or both arguments are infinite.

Right, that's what I assumed that you meant. I can't think of anything
better, either, because I like the fact that two arguments are there so
that you can visually see which sides are bounded/unbounded.

I suppose we could have constructors like: range(text, subtype)
and range(subtype, text)
where the text field is used to specify "infinity". But that has the
obvious problem "what if the subtype is text?". So, of course, we make a
special new pseudotype to represent infinity... ;)

But seriously, your idea is starting to look more appealing.

To get into some more details: how exactly would this constructor be
generated on the fly? Clearly we want only one underlying C function
that accepts something like: range_internal(lower, upper, flags, Oid rangetype)
So how do we get the rangetype in there? I suppose a default 4th
argument?

That would be kind of an interesting option, but what if someone
actually specified that 4th argument? We couldn't allow that.

Also, are default arguments always applied in all the contexts where
this function might be called?

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Old postgresql repository
Next
From: Robert Haas
Date:
Subject: Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt