Hi Markus,
Thanks for the prompt reply. From a quick perusal of the libpq source code
(postgres 8.1.8), it appears that PQescapeString() is not 100% safe to use
for escaping the conninfo parameters. The problem is that PQescapeString()
invokes PQescapeStringInternal() with a few parameters that control how the
escaping is performed, in particular std_strings and encoding. The values
for these parameters are taken from the static variables static_std_strings
and static_client_encoding, which default to appropriate values (false and
PG_SQL_ASCII, respectively). Unfortunately, the static variables are
overwritten by pqSaveParameterStatus() when a new connection is initiated --
so the behavior of PQescapeString() is dependent on the last connection that
was created.
The unescaping of the conninfo parameters is performed in conninfo_parse(),
which doesn't take static_std_strings or static_client_encoding into
account. So the only way to guarantee that escaping is performed
appropriately is to do it ourselves.
All parameters in conninfo are optional; see:
http://www.postgresql.org/docs/current/interactive/libpq-connect.html
The passed string can be empty to use all default parameters, or it can
contain
one or more parameter settings separated by whitespace. Each parameter
setting
is in the form keyword = value. Spaces around the equal sign are optional.
To
write an empty value or a value containing spaces, surround it with single
quotes, e.g., keyword = 'a value'. Single quotes and backslashes within the
value must be escaped with a backslash, i.e., \' and \\.
(The conninfo string can be empty, but not NULL, hence conninfo ? conninfo :
"" in my patch.)
Cheers,
Tony
On 3/23/07, Markus Hoenicka <[EMAIL PROTECTED]> wrote:
Hi Antal,
Quoting Antal Novak <[EMAIL PROTECTED]>:
> 1. Characters were not being escaped properly, so if you had a backslash
or
> apostrophe in one of the parameter strings (e.g. username, password,
etc.)
> it would lead to an invalid conninfo string being sent to PQconnectdb().
> The PostgreSQL documentation for PQconnectdb() specifies that "Single
quotes
> and backslashes within the value must be escaped with a backslash,
> i.e., \'and
> \\."
Now that you mention it, the same problem is likely to affect all
other drivers as well. While we're at it, we should tackle this
problem once and for all.
I was just wondering whether we should use the client library quoting
functions (PQescapeString in the case of PostgreSQL) instead of
rolling our own. Would you mind checking whether this gives the same
result with less code?
>
> 2. There was no way to completely omit values from the conninfo
string. The
> conninfo_kludge variable took care of omitting "host" and "port" if they
> were not specified, but the same was not done for "user" -- so there was
no
> way to tell libpq to use the default user name. In this patch, I've
made
> all parameters optional, so all NULL parameter values are actually
omitted
> from the conninfo string, rather than making NULL equivalent to an empty
> string.
>
This is a reasonable patch for sure. If these values are optional for
the PostgreSQL client library, the drivers should treat them as
optional as well. I'll have a closer look on the weekend.
regards,
Markus
--
Markus Hoenicka
[EMAIL PROTECTED]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
