Re: log bind parameter values on error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Alexey Bashtanov <bashtanov@imap.cc>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-12-09T17:42:27Z
Lists: pgsql-hackers
I wrote: > Alvaro Herrera <alvherre@2ndquadrant.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
Commits
-
Emit parameter values during query bind/execute errors
- ba79cb5dc841 13.0 landed
-
Add backend-only appendStringInfoStringQuoted
- 6cafde1bd43f 13.0 landed