On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Farina <dan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
