Re: Default connection parameters for postgres_fdw and dblink

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-25 08:38:10
Message-ID: A737B7A37273E048B164557ADEF4A58B057CB0E0@ntex2010a.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> It struck me while looking at the regression test arrangements for
> postgres_fdw that as things are set up, the default username for
> outgoing connections is going to be that of the operating system
> user running the postmaster. dblink is the same way.
>
> Now, this might not be the world's worst default, but it's got to be a
> pretty bad one. The OS username of the server isn't really supposed to
> be exposed at all on the SQL level. And to the extent that it matches
> the bootstrap superuser's SQL name, it's still a non-POLA-satisfying
> default for any user other than the bootstrap superuser.
>
> IMO it would make a lot more sense for the default to be the name of the
> current database user. Either that, or insist that the outgoing
> username not be defaultable at all; though I'm not sure we can do the
> latter without breaking the regression tests, since those are supposed
> to be agnostic as to the name of the superuser running them.
>
> A related issue is that libpq will happily acquire defaults from the
> server's environment, such as PGPORT. This seems like it's also
> exposing things that shouldn't be exposed. Unfortunately, I think we're
> depending on that for the dblink and postgres_fdw regression tests to
> work at all when the postmaster is listening to a nondefault port (ie,
> "make check").
>
> Is there a better way to handle all this? It may be too late to rethink
> dblink's behavior anyhow, but perhaps it's not too late to change
> postgres_fdw. I think though that once we let 9.3 out the door, it
> *will* be too late to make any major changes, because postgres_fdw's
> usage is going to go through the roof now that it can do remote updates.

I agree that this is an unhappy situation.

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.

That comes closest to DWIM in my opinion.

Speaking about exposing the server environment, I have been bitten
before by the fact that the default client encoding is taken from
the server's PGCLIENTENCODING at postmaster start time, but that's
slightly off topic.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-25 09:23:47 Re: backward incompatible pg_basebackup and pg_receivexlog
Previous Message Albe Laurenz 2013-03-25 08:17:04 Re: adding support for zero-attribute unique/etc keys