From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types, constructors, and the type system |
Date: | 2011-07-06 16:22:13 |
Message-ID: | 1309969333.3012.114.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-06 16:40:39 | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt |
Previous Message | Robert Haas | 2011-07-06 15:59:09 | Re: Old postgresql repository |