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
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 |