Re: log bind parameter values on error
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
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-09T21:35:21Z
Lists: pgsql-hackers
Greg Stark <stark@mit.edu> writes: > On Mon, 9 Dec 2019 at 15:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Meh ... people will inevitably complain that they needed to see the >> whole value, and we'll end up having to add another configuration >> variable. Let's not go there just yet. > I haven't been following this whole thread but my initial reaction is > that this particular configuration parameter would actually carry it's > weight. Possibly so. I was mainly objecting to changing existing behaviors without offering any configuration recourse for getting back the existing behavior. Although it would be sensible to allow logging of parameter values to be controlled by a new GUC, it's less clear to me that the same GUC ought to control what plpgsql's language feature print_strict_params does. So there would be room for discussion about that even if we agreed on making this configurable. regards, tom lane
Commits
-
Emit parameter values during query bind/execute errors
- ba79cb5dc841 13.0 landed
-
Add backend-only appendStringInfoStringQuoted
- 6cafde1bd43f 13.0 landed