Jaime Casanova wrote:
On Mon, Sep 14, 2009 at 1:34 PM, Andrew Chernow <a...@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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
