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/
