Re: dblink: add polymorphic functions.
| От | Corey Huinker |
|---|---|
| Тема | Re: dblink: add polymorphic functions. |
| Дата | |
| Msg-id | CADkLM=cYdDx9SXMjpzwD_uHtnnAy3WV=UvVvF9FChjCNv0eV7A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: dblink: add polymorphic functions. (Joe Conway <mail@joeconway.com>) |
| Ответы |
Re: dblink: add polymorphic functions.
|
| Список | pgsql-hackers |
On Wed, Jul 8, 2015 at 12:21 PM, Joe Conway <mail@joeconway.com> wrote:
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?
-----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.
В списке pgsql-hackers по дате отправления: