From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(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:51:50 |
Message-ID: | CA+Tgmob4AtC-W60570a3eE4it2gJhkchTShODwSe7gj=1TsYRQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 6, 2011 at 12:22 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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 think that the C function could call get_call_result_type() and get
the return type OID back via the second argument.
> Also, are default arguments always applied in all the contexts where
> this function might be called?
Uh, I'm not sure. But I don't see why it would need different
handling than any other function which takes default arguments. It
shouldn't be needed during bootstrapping or anything funky like that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-07-06 17:04:00 | Re: Range Types, constructors, and the type system |
Previous Message | Robert Haas | 2011-07-06 16:40:39 | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt |