On 3 February 2018 at 11:46, Tom Lane <t...@sss.pgh.pa.us> wrote: > Chapman Flack <c...@anastigmatix.net> writes: > > ... which led me to the idea of a function parameter > > declaration, putting the function definer in control of what > > bits should get redacted. > > +1 for thinking outside the box, but ... > > > Would anyone else see some value in this capability? Could it > > (or some suitable restriction of it) seem implementable, or would > > the complications be overwhelming? > > ... the problem with this idea is that knowledge that the item ought to be > hidden would be obtained only very late in the parsing process. So for > example if you fat-fingered something just to the left of the function > call in the query text, or the name of the function itself, your password > would still get exposed in the log. > > This indeed is the core problem with every proposal I've seen for > semantics-based log filtering. Error logging needs to be considered > as a very low-level operation, because reports may come out when > little if anything is known about the real semantics of the query. > > About the only time I think it's really viable to pursue is if it's restricted to bind parameters. We only log those later and more selectively as it is, so it seems much more reasonable to say "I never want <parameter X> to appear in the logs".
That said, I'm not sure it can be done at the function-interface level, or if it'd have to be done in the Bind message to make it reliable and available early enough. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
