Re: dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 11:29 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 07/07/2015 10:22 PM, Michael Paquier wrote:
> >> On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway <mail(at)joeconway(dot)com>
> >> wrote:
> >>> That explains why the first example works while the second does
> >>> not. I'm not sure how hard it would be to fix that, but it
> >>> appears that that is where we should focus.
> >>
> >> Wouldn't it be fine if we drop some of the functions proposed
> >> without impacting the feature? Most of the functions overlap with
> >> each other, making us see the limitations we see.
> >>
> >> Hence, wouldn't it be enough to just have this set of functions in
> >> the patch? dblink_get_result(text, bool, anyelement) dblink (text,
> >> text, boolean, anyelement) dblink_fetch (text, text, int, boolean,
> >> anyelement)
> >
> > I think new using function names is better especially if we are only
> > going to support a subset. I have no idea what to call them however.
> > Did someone else suggest dblink_any(), etc?
> >
> > I also think that the ultimately best solution is (what I believe to
> > be spec compliant) SRF casting, but I guess that could be a task for a
> > later day.
>
> totally agree. Even if we had SRF casting, OP's patch has value
> because of abstraction benefits. Also given that we are in an
> extension we can relax a bit about adding extra functions IMO.
>
> merlin
>

I'm fine with separate functions, that's what I originally proposed to Joe
way-back when I was trying to figure out if such a thing was possible.

That would also allow me to move the rowtype parameter to the first
parameter, much more in line with other polymorphic functions. And that
*might* resolve the parameter ambiguity issue

Questions:
Would moving rowtype to the first parameter resolve the parameter
ambiguity issue?
Would we want new function names anyway?
How much of a goal is reducing function count?

The following suffixes all make a degree of sense to me:
_any()
_to_row()
_to_rowtype()
_to_recordset() -- borrowing from json[b]_to_recordsset() and
json[b]_populate_recordset(), the first functions polymorphic functions to
come to mind.

IMO, _to_recordset() would win on POLA, and _any() would win on terse.