On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway <m...@joeconway.com> wrote:
> 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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to