From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pie-in-sky idea: 'sensitive' function parameters |
Date: | 2018-02-03 03:46:07 |
Message-ID: | 14280.1517629567@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <chap(at)anastigmatix(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-02-03 06:58:33 | Re: [HACKERS] proposal: schema variables |
Previous Message | Peter Geoghegan | 2018-02-03 03:26:59 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |