On Wed, Mar 27, 2013 at 8:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:>>
>> 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.
In my meta-experience, "nobody" really wants defaults in that
configuration anyway, and if they do, most of them would be
appreciative of being notified positively of such a problem of relying
on connection defaults (maybe with a warning at first at most?). In
this case, such an abrupt change in the contrib is probably fine.
From the vantage point I have: full steam ahead, with the sans GUC
solution...it's one less detailed GUC in the world, and its desired
outcome can be achieved otherwise. I'd personally rather open myself
up for dealing with the consequences of this narrow change in my own
corner of the world.
This anecdote carries a standard disclaimer: my meta-experience
doesn't include all use cases for everyone everywhere.
--
fdr