| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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 21:35:21 |
| Message-ID: | 11425.1575927321@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Mon, 9 Dec 2019 at 15:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2019-12-09 21:36:15 | Re: VACUUM memory management |
| Previous Message | Andres Freund | 2019-12-09 21:32:17 | Re: [Proposal] Level4 Warnings show many shadow vars |