Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink

On Tue, Apr 1, 2014 at 05:06:08PM +0200, Adrian Vondendriesch wrote:
> Am 01.04.2014 16:32, schrieb Tom Lane:
> > Adrian Vondendriesch <adrian(dot)vondendriesch(at)credativ(dot)de> writes:
> >> I patched the function conninfo_array_parse() which is used by
> >> PQconnectStartParams to behave like PQsetdbLogin. The patch also
> >> contains a document patch which clarify "unspecified" parameters.
> >
> > I see no documentation update here. I'm also fairly concerned about the
> > implication that no connection parameter, now or in future, can ever have
> > an empty string as the correct value.
>
> If we want to preserve the possibility to except an empty string as
> correct value, then pgbench should initialise some variables with
> NULL instead of empty string.
>
> Moreover it should be documented that "unspecified" means NULL and not
> empty string, like in PQsetdbLogin.
>
> However, attached you will find the whole patch, including documentation.

Where do we want to go with this? Right now, PQsetdbLogin() and
PQconnectdbParams() handle zero-length strings differently.
PQsetdbLogin() treats it as unspecified, while PQconnectdbParams() does
not, and our documentation on PQconnectdbParams() is unclear on this.

It seems we can either change pgbench or libpq, and we should document
libpq in either case.

Also, the second sentence seems wrong:

The passed arrays can be empty to use all default parameters,
or can contain one or more parameter settings. They should
be matched in length. Processing will stop with the last
non-<symbol>NULL</symbol> element of the <literal>keywords</literal>
array.

Doesn't it stop with first NULL value? For example, if the array is
"a", NULL, "b", NULL, it stops at the first NULL, not the second one.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +