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

Jaime Casanova wrote:
> On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow <ac@esilo.com> wrote:
>> Jaime Casanova wrote:
>>> i extracted the functions to connect that Heikki put on psql in his
>>> patch for determining client_encoding from client locale and put it in
>>> libpq so i follow the PQconnectdbParams(* params[]) approach.
> [...]
>> The below posts agreed on a two argument version of parallel arrays
>> (keywords, values):
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00533.php
>> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00559.php
>>
> 
> actually, Tom said: "it's hard to be sure which way is
> actually more convenient without having tried coding some likely
> calling scenarios both ways."
> 

Aahhh, correct you are Daniel son :)

> personally, i think it will cause more problems than solve because you
> have to be sure your arrays have relationship between them...
> 

A strict relationship exists either way.

>> There is also the idea of passing an array of structs floating around, NULL
>> terminated list or include an additional argument specifying element count.
>>
> 
> one more variable to the equation, more innecesary complexity and
> another source of errors, IMO...

one more variable or one more element, both of which cause problems if 
omitted/incorrect.

const char *params[] =  {"host", "blah.com", "port", "6262", NULL, NULL};

// compiler enforces relationship
const PGopotion opts[] =  {{"host", "blah.com"}, {"port", "6262"}, {NULL, NULL}};

IMHO, the struct approach seems like a cleaner solution.

Any chance of using a term other than "params"?  Maybe "options" or 
"props"?

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/