Jaime Casanova <jcasa...@systemguards.com.ec> writes:
> On Mon, Jul 6, 2009 at 10:00 AM, Heikki
> Linnakangas<heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
