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:42:27
Message-ID: 30654.1575913347@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> 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.

Actually, on second thought --- the issue here is not so much how much new
code shows up in libpgcommon, and more that executables using stringinfo.o
will now find themselves pulling in all of wchar.o, where before they
might've pulled in none of it. We need to look at how much code bloat
ensues. In the end it might be smart to put this new functionality in
some separate source file instead of dropping it into stringinfo.c.
(It could also be that all the executables that need stringinfo.o are
already pulling in wchar functionality for other reasons, but we should
check the code-size implications before assuming this is fine.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2019-12-09 17:59:52 Index corruption / planner issue with one table in my pg 11.6 instance
Previous Message Mark Dilger 2019-12-09 17:32:25 Re: [Proposal] Level4 Warnings show many shadow vars