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