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

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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