On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Farina <daniel@heroku.com> writes:
>> I will try to make time for this, although it seems like the general
>> approach should match pgsql_fdw if possible. Is the current thinking
>> to forward the settings and then use the GUC hooks to track updates?
>
> That's not what I had in mind for postgres_fdw --- rather the idea is to
> avoid needing on-the-fly changes in remote-side settings, because those
> are so expensive to make. However, postgres_fdw is fortunate in that
> the SQL it expects to execute on the remote side is very constrained.
> dblink might need a different solution that would leave room for
> user-driven changes of remote-side settings.
Okay, I see. So inverting the thinking I wrote earlier: how about
hearkening carefully to any ParameterStatus messages on the local side
before entering the inner loop of dblink.c:materializeResult as to set
the local GUC (and carefully dropping it back off after
materializeResult) so that the the _in functions can evaluate the
input in the same relevant GUC context as the remote side?
That should handle SET actions executed remotely.
Otherwise it seems like a solution would have to be ambitious enough
to encompass reifying the GUCs from the afflicted parsers, which I
surmise is not something that we want to treat right now.
--
fdr
