Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)

Jaime Casanova <jcasanov@systemguards.com.ec> writes:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas<heikki.linnakangas@enterprisedb.com> wrote:
>> Could we
>> have a version of PQconnectdb() with an API more suited for setting the
>> params programmatically? The PQsetdbLogin() approach doesn't scale as
>> parameters are added/removed in future versions, but we could have
>> something like this:
>> 
>> PGconn *PQconnectParams(const char **params)
>> 
>> Where "params" is an array with an even number of parameters, forming
>> key/value pairs. Usage example:
>> 
> [...]
>> 
>> Another idea is to use an array of PQconninfoOption structs:
>> 
>> PQconn *PQconnectParams(PQconninfoOption *params);
>> 

> this sounds like a good idea, specially if we add new parameters to
> the conninfo string and want postgresql's client applications to use
> them.

> any one have a preference here?

Let's leave PQconninfoOption out of this --- it's bizarrely
overcomplicated for what we need here.  For example, it would not be
clear to a user which fields of a PQconninfoOption he actually needed
to set up for this purpose.

The alternative I would consider is two parallel arrays, one for
keywords and one for values:

PGconn *PQconnectParams(const char **keywords, const char **values)

on the grounds that the keyword set is likely to be a true constant
whereas the values won't be.  But it's hard to be sure which way is
actually more convenient without having tried coding some likely
calling scenarios both ways.

I don't have much of a preference for count vs. terminating null
--- I could see either one being easier.
        regards, tom lane