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
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 |