Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
От | Jaime Casanova |
---|---|
Тема | Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) |
Дата | |
Msg-id | 3073cc9b0909141154j12694fa1la6ab87951845028@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) (Andrew Chernow <ac@esilo.com>) |
Ответы |
Re: new version of PQconnectdb was:(Re: [HACKERS] Determining
client_encoding from client locale)
|
Список | pgsql-hackers |
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." so i tried one scenario. :) do you think is worth the trouble make the other approach? i could make the patch if someone is interested... personally, i think it will cause more problems than solve because you have to be sure your arrays have relationship between them... > 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... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
В списке pgsql-hackers по дате отправления: