Re: Default connection parameters for postgres_fdw and dblink

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default connection parameters for postgres_fdw and dblink
Date: 2013-03-27 14:47:46
Message-ID: 11357.1364395666@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

(I guess we could have a switch to control whether the environment gets
cleared, so that anybody who really needs the old behavior could still
get it. But ugh.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-03-27 14:50:13 Re: [COMMITTERS] pgsql: sepgsql: Support for new post-ALTER access hook.
Previous Message Michael Paquier 2013-03-27 14:37:54 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory