Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
Date
Msg-id 24640.1252597824@sss.pgh.pa.us
Whole thread Raw
In response to new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: COPY enhancements
Next
From: Emmanuel Cecchet
Date:
Subject: Re: COPY enhancements