Re: control max length of parameter values logged

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alexey Bashtanov <bashtanov(at)imap(dot)cc>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: control max length of parameter values logged
Date: 2020-03-15 23:48:33
Message-ID: 20200315234833.GA31110@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Mar-14, Tom Lane wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I am sorry --- I am confused. Why are we truncating or allowing control
> > of truncation of BIND parameter values, but have no such facility for
> > queries. Do we assume queries are shorter than BIND parameters, or is
> > it just that it is easier to trim BIND parameters than values embedded
> > in non-EXECUTE queries.
>
> The cases that Alvaro was worried about were enormous values supplied
> via bind parameters. We haven't heard comparable complaints about
> the statement text.

To be more precise, I have seen cases of enormous statement text, but
those are fixed precisely by moving the bulk to parameters. So the
ability to trim the parameter is important. I've never seen a very
large query without the bulk being parameterizable.

> Also, from a security standpoint, the contents
> of the statement text are way more critical than the contents of
> an out-of-line parameter; you can't do SQL injection from the latter.

That's a good point too.

> So I think the audience for trimming would be a lot smaller for
> statement-text trimming.

Nod. (I think if we really wanted to trim queries, it would have to be
something semantically sensible, not just trim whatever is at the end of
the statement literal. Say, only trim parts of the where clause that
are of the form "something op constant", and rules like that, plus put
placeholders to show that they were there. This sounds a lot of work to
figure out usefully ...)

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-16 00:20:49 Re: proposal: new polymorphic types - commontype and commontypearray
Previous Message Tom Lane 2020-03-15 23:17:51 More weird stuff in polymorphic type resolution