Re: psql 9.1 alpha5: connection pointer is NULL
От | Christoph Berg |
---|---|
Тема | Re: psql 9.1 alpha5: connection pointer is NULL |
Дата | |
Msg-id | 20110422113544.GC3417@msgid.df7cb.de обсуждение исходный текст |
Ответ на | Re: psql 9.1 alpha5: connection pointer is NULL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: psql 9.1 alpha5: connection pointer is NULL
|
Список | pgsql-hackers |
Re: Tom Lane 2011-04-03 <1397.1301782258@sss.pgh.pa.us> > Yeah, that's clearly a bug --- fix committed, thanks for the patch! > > It could explain Devrim's report if the parameters passed by psql had > some problem that was detectable by conninfo_array_parse(). That seems > a bit unlikely, but I did think of one possibility: if Devrim was > testing 9.1 psql with a 9.0 libpq (perhaps due to an rpath issue) > then 9.0 libpq would spit up on client_encoding, which wasn't a legal > connection parameter in 9.0. Hi, I'm still seeing that problem: 9.1 HEAD compiled in my $HOME, with Debian's 9.0.1-2 libpq5 in /usr/lib: $ LC_ALL=C bin/psql psql: connection pointer is NULL Upgrading to libpq5 9.0.4-1 makes things a bit better: $ LC_ALL=C bin/psql psql: invalid connection option "client_encoding" Setting LD_LIBRARY_PATH fixes it. Arguably, this is not the "standard" setup, but one that will probably be quite frequent for someone trying 9.1 in their ~. Shouldn't psql try to work with older libpq versions by omitting client_encoding? Setting an RPATH seems like an ugly solution. (I'm not arguing for a SONAME bump, but this is kind of an ABI change.) Christoph -- cb@df7cb.de | http://www.df7cb.de/
В списке pgsql-hackers по дате отправления: