Re: libpq PGHOST
От | Peter Eisentraut |
---|---|
Тема | Re: libpq PGHOST |
Дата | |
Msg-id | Pine.LNX.4.21.0010022026510.1205-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: libpq PGHOST (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpq PGHOST
|
Список | pgsql-hackers |
Tom Lane writes: > > The current behaviour of libpq is to use Unix sockets whenever the host > > parameter (PGHOST or setdbLogin argument) is NULL/unset. > > Could we extend that to also use Unix sockets if the parameter is set but > > empty? > Seems reasonable, since the current behavior in that case is useless: > $ PGHOST='' psql > psql: connectDBStart() -- unknown hostname: > $ > Backwards compatibility with that doesn't seem necessary ... After further investigation, there seems to be a larger unset/empty mess. When using PQconnectdb(), a NULL parameter (keyword was not given at all) means to use the environment variable, an explicit empty argument is used as is. When using PGsetdbLogin(), however both NULL and empty arguments cause the environment variable to be used. (An environment variable is always used as is.) Consequently, if PGHOST is set in the environment and your application is using PGsetdbLogin(), then it's just impossible to get a Unix socket connection. (Note that this is independent of the proposed change, because PGHOST may be set to some "real" string that you might wish to override.) If we were to sort this out, then I think we'd need to change PQsetdbLogin() to take empty arguments uniformly "as is", and make the change to make Unix sockets also with an empty host parameter, as proposed. Then you could use psql -h '' to request a Unix socket explicitly. Somewhat related: peter=# create function "" () returns int as 'select 42' language 'sql'; CREATE peter=# select ""(); ----42 (1 row) That was probably not the plan. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: