Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
От | Andrew Chernow |
---|---|
Тема | Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) |
Дата | |
Msg-id | 4AA89299.7050401@esilo.com обсуждение исходный текст |
Ответ на | new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) (Jaime Casanova <jcasanov@systemguards.com.ec>) |
Список | pgsql-hackers |
>> PGconn *PQconnectParams(const char **params) >> >> Where "params" is an array with an even number of parameters, forming >> key/value pairs. Usage example: >> Maybe use the term properties (props for short) or options instead of params? Params is already in heavy use. How about PQconnectProps(...) or PQconnectOptions(...)? >> 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 Here's another idea, parallel arrays: PGconn *PQconnectProps(const char **names, const char **values); PGconn *PQconnectOptions(const char **names, const char **values); To build on the struct idea, maybe PGprop or PGoption instead of PQconninfoOption. Also, add an argument specifying the number of props/options. PGconn *PQconnectProps(const PGprop *props, int nProps); PGconn *PQconnectOptions(const PGoption *options, int nOptions); > any one have a preference here? > I like the struct approach. I personally prefer specifying the element count of an array, rather than using a NULL terminating element. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
В списке pgsql-hackers по дате отправления: