Re: log bind parameter values on error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log bind parameter values on error
Date: 2019-12-09 17:31:12
Message-ID: 28867.1575912672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Dec-07, Tom Lane wrote:
>> It is a very bad idea that this is truncating text without regard to
>> multibyte character boundaries.

> I see four possible ways forward, with nuances. In order of preference:

> 1. change enough of the build system so that pg_encoding_mbcliplen is
> available. (Offhand I see no reason why we couldn't move the
> function from mbutils.c to wchar.c, but I haven't tried.)

I'd be in favor of this if it doesn't turn out to require nasty
contortions. My gut feeling (like yours, without having looked) is that
the incremental amount of code to be moved into wchar.c wouldn't be much.

BTW, not really the fault of this patch, but I wonder if we shouldn't
make an effort to push the FRONTEND-available parts of wchar.c into
src/common, just to make the system structure and build rules less
confusing. I think the current situation only exists because this
code predates our invention of src/common.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2019-12-09 17:32:25 Re: [Proposal] Level4 Warnings show many shadow vars
Previous Message Ranier Vilela 2019-12-09 17:28:19 RE: [Proposal] Level4 Warnings show many shadow vars