Re: dblink: add polymorphic functions.
| От | Michael Paquier |
|---|---|
| Тема | Re: dblink: add polymorphic functions. |
| Дата | |
| Msg-id | CAB7nPqTBU2b3EoR6giGFTFTn6w16-cOQfxq5mbEn2--=Z1k8bw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: dblink: add polymorphic functions. (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: dblink: add polymorphic functions.
|
| Список | pgsql-hackers |
On Mon, Jul 6, 2015 at 4:23 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Jul 6, 2015 at 10:00 AM, Joe Conway <mail@joeconway.com> wrote:
>> I wonder if it isn't better to just loop through all the args with
>> get_fn_expr_argtype() every time and then test for the exact signature
>> match? Another alternative might be to create a wrapper C function for
>> each variant SQL function, but that seems like it could also get
>> messy, especially with dblink_record_internal() since we would have to
>> deal with every variant of all the external facing callers.
>> Thoughts?
>
> Yeah, particularly the use of first_optarg makes things harder to
> follow in the code with this patch. A C wrapper has the disadvantage
> to decentralize the argument checks to many places making the flow
> harder to follow hence using get_fn_expr_argtype() with PG_NARGS would
> be the way to go, at least to me. This way, you can easily find how
> many arguments there are, and which value is assigned to which
> variable before moving on to the real processing.
Just to be clear I mean that:
if (PG_NARGS() == 5)
{ if (get_fn_expr_argtype(fcinfo->flinfo, 1) == TYPEOID) var = PG_GETARG_BOOL(1) [...]
}
else if (PG_NARGS() == 4)
{ [...]
}
else [...]
--
Michael
В списке pgsql-hackers по дате отправления: