Re: dblink: add polymorphic functions.
От | Merlin Moncure |
---|---|
Тема | Re: dblink: add polymorphic functions. |
Дата | |
Msg-id | CAHyXU0z8cD4vrCY8qnk1WR+DLn_oxNHnJL+QDWmB3zrc7opgXw@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 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
В списке pgsql-hackers по дате отправления: