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

On Tue, Mar 12, 2013 at 11:51 AM, Tom Lane  wrote:
> Daniel Farina  writes:
>> 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?
>
> Yeah, watching the remote side's datestyle and intervalstyle and
> matching them (for both input and output) would probably work.

Alright, so I've been whacking at this and there's one interesting
thing to ask about: saving and restoring the local GUCs.  There are a
bunch of things about GUCs besides their value that are maintained,
such as their 'source', so writing a little ad-hoc save/restore is not
going to do the right thing.  Luckily, something much closer to the
right thing is done for SET LOCAL with transactions and
subtransactions, to push and pop GUC contexts:
 guc.h:
 extern int NewGUCNestLevel(void); extern void AtEOXact_GUC(bool isCommit, int nestLevel);

By and large looking at the mechanics of these two functions, the
latter in particular has very little to do with the transaction
machinery in general.  It's already being called from a bunch of
places that don't, to me, seem to really indicate a intrinsic
connection to transactions, e.g. do_analyze_rel, ri_triggers, and
postgres_fdw.  I think in those cases the justification for settings
of 'isCommit' is informed by the mechanism more than the symbol name
or its comments.  I count about ten call sites that are like this.

So, I can add one more such use of AtEOXact_GUC for the dblink fix,
but would it also be appropriate to find some new names for the
concepts (instead of AtEOXact_GUC and isCommit) here to more
accurately express what's going on?

I'll perhaps do that after finishing up the dblink fix if I receive
some positive response on the matter.  However, if for some reason I
*shouldn't* use that machinery in dblink, I'd appreciate the guidance.

--
fdr