Re: dblink: add polymorphic functions.
От | Corey Huinker |
---|---|
Тема | Re: dblink: add polymorphic functions. |
Дата | |
Msg-id | CADkLM=fZ=bgoAxk4tCF-DG03iuOnCFeSbx0c0pU_Sz8fWGcT-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: dblink: add polymorphic functions. (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: dblink: add polymorphic functions.
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: