Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Alvaro Herrera wrote:
> >> This bit seems strange ... I think we just do strcmp() to compare sqlstates?
> > Uh, the PQresultErrorField is a string, while
> > ERRCODE_INVALID_PASSWORD_SPECIFICATION is a 4-byte value in base-64.
> > Yea, it's true. For excitement, see the MAKE_SQLSTATE macro.
> I don't particularly believe in doing things this way: I think that
> libpq should just hardwire the string the same as it's doing for the
> other specific sqlstate it's checking for. If we do this at all,
> then we are effectively embedding that sqlstate value in the protocol.
> We are not going to be able to change it later. Doing it like this
> opens us up to randomly using errcodes in the frontend without realizing
> that we've thereby lost the freedom to change them.
> Even if you insist on including errcodes.h into the frontend code
> despite that, this is an ugly brute-force way of solving the problem.
> The intended way of solving the problem was to redefine MAKE_SQLSTATE
> before including the file, in .c files where you need a different
OK, just defined it as a constant string. I am not a big fan of
redefining macros, especially ones that are referenced in later include
Is this going to cause problems for client applications that only test
for ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION? I doubt many of them
are testing for just the first two digits.
Is there anywhere else we should be testing for this new sqlstate value?
Updated patch attached.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-03-11 23:38:23|
|Subject: Re: Warning about invalid .pgpass passwords |
|Previous:||From: Alvaro Herrera||Date: 2010-03-11 22:05:05|
|Subject: Re: plperl db access documentation enhancement|