On Wed, Mar 27, 2013 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Mar 25, 2013 at 4:38 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>>> If possible, I would suggest the following defaults (that's what I as
>>> a user would expect without thinking too hard):
>>> 1) Default the user to the current effective database user.
>>> 2) Default the port to 5432.
>>> 3) Default the database name to the current database name.
>
>> +1.
>
> I think (2) should be "default to whatever the configure-selected
> default port is" --- not hard-wired to 5432.
>
> I'm also a bit unclear on what the argument is for (3), as opposed to
> following the default that we use in every other context, namely set
> dbname equal to username.
Well, those both seem reasonable alternative proposals. No argument here.
>> Yeah. I really hate environment variables as a way of setting
>> defaults for things, because they tend to start creeping into
>> unfortunate places. It's not so bad to have one or two, but when you
>> start to have PGDATA, PGPORT, PGUSER, PGSERVICE, PGSERVICEFILE,
>> PGSSLMODE, PGCONNECT_TIMEOUT, PGHOST, PGHOSTADDR, PGREALM, PGOPTIONS,
>> PGAPPNAME, PGREQUIRESSL, PGSSLCOMPRESSION, PGSYSCONFDIR, PGLOCALEDIR,
>> PGSSLROOTCERT, PGSSLCERT, PGGEQO, PGTZ, PGDATESTYLE, PGCLIENTENCODING,
>> PGKRBSRVNAME, PGGSSLIB, PGPASSFILE, OLDDATADIR, NEWDATADIR, OLDBINDIR,
>> NEWBINDIR, and probably a few others I'm missing, it becomes very
>> difficult to sanitize an environment (such as the postmaster) against
>> undesirable intrusions.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
