Re: Question about password character in ECPG's connection string

Luca Ferrari <fluca1978(at)gmail(dot)com> writes:
> On Thu, Aug 29, 2019 at 1:08 PM Egashira, Yusuke
> <egashira(dot)yusuke(at)jp(dot)fujitsu(dot)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