Re: Question about password character in ECPG's connection string - Mailing list pgsql-general

From Tom Lane
Subject Re: Question about password character in ECPG's connection string
Date
Msg-id 12241.1567270379@sss.pgh.pa.us
Whole thread Raw
In response to Re: Question about password character in ECPG's connection string  (Luca Ferrari <fluca1978@gmail.com>)
List pgsql-general
Luca Ferrari <fluca1978@gmail.com> writes:
> On Thu, Aug 29, 2019 at 1:08 PM Egashira, Yusuke
> <egashira.yusuke@jp.fujitsu.com> wrote:
>> According to my tests, I think that the ECPG's connection_option seems not to accept '&' character as password
anyhow...
>> ECPG CONNECT's connection_option seems to have some restricted characters.

> As far as I understand from
>
<https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/ecpg/ecpglib/connect.c;h=ec01f67b61d5e8f0b88f84346451d2135a78b777;hb=HEAD#l603>
> unwanted characters are '&' and '='. Even if the connetion string
> seems an URL, it is managed in plain text without any sort of
> escaping.

Yeah, the format of the "options" string is not mentioned at all in the
ECPG documentation, but from looking at the code, it's
    keyword=value[&keyword=value...]
where the keywords are the same option keywords recognized by
PQconnectdbParams.  Also, you can write spaces just before
(but not after) any keyword or value.

Given this, you can't write '=' in a keyword (which is moot because
none of them have '=') and you can't write '&' in a value.

Note that the ECPG documentation does not suggest that you can set
either username or password this way.  I'm inclined to think that it's
a bad idea to do so, even if it seems to work.  At minimum it'd mean
that ecpglib has the wrong idea of what the connection's username is,
which seems likely to bite people someday.

If you're not trying to game the system like that, the set of
characters you might actually need in a value seems fairly
constrained, so the restriction about '&' doesn't seem like a huge
problem.  If we introduced URI-style escaping, we'd just make the
problem of funny characters worse, because then '%' would also become
magic.  An alternative that doesn't risk breaking cases that work
today is to say that you can write '&&' to mean a literal '&', but
that seems kind of icky; there's nothing else that does that.

On the whole I'm content with the way the code works now, but we do
need to document it.

            regards, tom lane



pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: echo work alike in SQL
Next
From: Tony Shelver
Date:
Subject: Re: SQL equivalint of #incude directive ?