Re: expand_dbname in postgres_fdw

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: expand_dbname in postgres_fdw
Date: 2017-07-26 18:51:59
Message-ID: 20225.1501095119@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, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>> According to F.34.1.1 at [1] passing connection string as dbname
>> option should work, so your question is valid. I am not aware of any
>> discussion around this on hackers.

> I kind of wonder if this had some security aspect to it? But not sure.

The main problem to my mind is that a connection string could possibly
override items meant to be specified elsewhere. In particular it ought
not be allowed to specify the remote username or password, because those
are supposed to come from the user mapping object not the server object.
I suspect you could break things by trying to specify client_encoding
there, as well.

In any case, I entirely reject the argument that the existing
documentation says this should work. It says that you can specify (most
of) the same fields that are allowed in a connection string, not that one
of those fields might be taken to *be* a connection string.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-07-26 19:03:37 Re: segfault in HEAD when too many nested functions call
Previous Message Alvaro Herrera 2017-07-26 18:44:10 Re: expand_dbname in postgres_fdw