Re: dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 12:21 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/08/2015 08:51 AM, Corey Huinker wrote:
> > Questions: Would moving rowtype to the first parameter resolve the
> > parameter ambiguity issue?
>
> Not for the existing functions but with new functions I don't think it
> matters. You would know to always ignore either the first or last
> argument when determining which variant was wanted.
>
> > Would we want new function names anyway?
>
> Yes, see above
>
> > How much of a goal is reducing function count?
>
> Do you mean reducing number of C functions or SQL functions?
>
>

C functions. Was there a reason (performance, style, etc) to have only one
function per function name, and let it suss out which signature call
happened this time, as opposed to having the signatures with defaulted
values implemented as either as C wrappers or SQL wrappers to C function
which can then assume the full-blown signature?

I'm asking because if making the C code more straightforward is a goal, and
wrapper overhead is minimal, then that could be a separate patch, either
preceding or following the polymorphic one.

UPDATE:
After less than an hour of recoding for the 3 _any() functions with full
signatures, I noticed that the C code would be exactly the for the
non-anyelement sets if we implemented the signatures with omitted
parameters as SQL wrappers (of course, the _any() ones would call the C
function without STRICT mode).

So this patch would result in less C code while still adding 3 new
functions. Can anyone think of why that wouldn't be the best way to go?

>
> The problem is that jsonb_to_recordset() does not behave like these
> new dblink functions in that it requires a runtime column definition
> list. It might be better to use something completely different, so I
> think _any() or maybe _to_any() is better.
>
> Any other ideas for names out there?
>
> Joe

>

_any() is what I'm going with, sticking with trailing anyelement to
highlight the "it's just like the function without the _any" aspect.

I'm also remembering to drop the --1.1 and restore the regression test case
I hijacked.