Christoph Berg <c...@df7cb.de> writes:
> 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"
Yes, this is unsurprising. The bug Joe Adams spotted was actually in
libpq 9.0.x, and it's fixed in 9.0.4. So now you get the expected
failure message instead of the opaque "connection pointer is NULL" one.
> 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?
No. It has never been the expectation that psql could work with a libpq
older than its own release, and I see no reason to try to make it true
now. In most past versions the behavior would have been even less
friendly than this, ie a coredump due to unresolvable library symbols or
some such.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
