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.
> 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?
regards, tom lane
