On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway <m...@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 <m...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers