Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Date
Msg-id 20140417012038.GW7443@momjian.us
Whole thread Raw
In response to Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink  (Adrian Vondendriesch <adrian.vondendriesch@credativ.de>)
List pgsql-hackers
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.vondendriesch@credativ.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.
Theyshould      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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: BGWorkers, shared memory pointers, and postmaster restart
Next
From: Andrew Dunstan
Date:
Subject: Re: assertion failure 9.3.4