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.