Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)

On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)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