Re: Default connection parameters for postgres_fdw and dblink

On Wed, Mar 27, 2013 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Mar 27, 2013 at 10:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> It's arguable that we should unsetenv all of these inside the postmaster
>>> (once it's absorbed the values from the ones it historically pays
>>> attention to), so that the postmaster environment does not impinge on
>>> the behavior of libpq inside a server process. This would cause a
>>> non-backwards-compatible change in the behavior of dblink, though.
>>> Are we okay with that?
>
>> I feel like unsetting all of these (or whatever the canonical list is)
>> in the postmaster is a bit like trying to bail out the ocean with a
>> bucket, but since a bucket appears to be the only instrument at hand,
>> sure, why not?
>
>> As far as breaking backward incompatibility goes, it doesn't strike me
>> as likely that anyone is relying on the current behavior, but on the
>> off chance that they are, do we have some other way for them to set
>> defaults? What I'm worried about with the current behavior is that
>> people will accidentally absorb behavior changes they don't want (or
>> that are insecure). But if there's no other way to set defaults
>> explicitly then you could we'd be ripping out a feature without
>> providing a replacement, something I am loathe to do.
>
> Use a service file maybe? But you can't have it both ways: either we
> like the behavior of libpq absorbing defaults from the postmaster
> environment, or we don't. You were just arguing this was a bug, and
> now you're calling it a feature.

Maybe we could compromise and call it a beature. Or a fug. In all
seriousness, it's in that grey area where most people would probably
consider this a surprising and unwanted behavior, but there might be a
few out there who had a problem and discovered that they could use
this trick to solve it.

In terms of a different solution, what about a GUC that can contain a
connection string which is used to set connection defaults, but which
can still be overriden? So it would mimic the semantics of setting an
environment variable, but it would be better, because you could do all
of the usual GUC things with it instead of having to hack on the
postmaster startup environment.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company