On Wed, Jul 8, 2015 at 11:29 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway <mail@joeconway.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@joeconway.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.