Re: psql 9.1 alpha5: connection pointer is NULL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christoph Berg <cb(at)df7cb(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql 9.1 alpha5: connection pointer is NULL
Date: 2011-04-22 14:35:02
Message-ID: 17566.1303482902@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Christoph Berg <cb(at)df7cb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2011-04-22 14:56:13 Re: "stored procedures"
Previous Message Greg Stark 2011-04-22 14:31:18 Re: fsync reliability