Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql
Date
Msg-id 20140324200028.GF15836@momjian.us
Whole thread Raw
In response to Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
On Sat, Mar 22, 2014 at 08:17:11PM -0400, Bruce Momjian wrote:
> On Sat, Mar 22, 2014 at 11:55:56AM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > OK, hearing nothing, I dug into this, and I think the solution is
> > > simpler than we thought.  Basically, the Assert is checking for the
> > > encoding value to be in a valid range, but the main code is also
> > > checking for an invalid encoding and returning PG_SQL_ASCII:
> >
> > Agreed that that's pretty useless.  I wonder though why these functions
> > are not coded like
> >
> >        return PG_VALID_ENCODING(encoding) ?
> >            ((*pg_wchar_table[encoding].mblen) ((const unsigned char *) mbstr)) :
> >            ((*pg_wchar_table[PG_SQL_ASCII].mblen) ((const unsigned char *) mbstr)));
> >
> > instead of the hard-to-read explicit range check.
>
> Agreed.  Modified patch attached.

Patch applied.  I did not backpatch because it only affects assert
builds, which I assume is only being done in head.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #8354: stripped positions can generate nonzero rank in ts_rank_cd
Next
From: Heikki Linnakangas
Date:
Subject: Re: BUG #9635: Wal sender process is using 100% CPU