Robert Haas writes:
> On Fri, May 29, 2020 at 3:26 PM Tom Lane wrote:
>> One missing part of that is that we'd need to support bind parameters
>> for utility statements, eg new password in ALTER USER. That's been
>> on the wish list for a long time anyway, of course. I think it's
>> mostly a ma
On 05/29/20 15:26, Tom Lane wrote:
> all of the simpler cases I can think of: aside from the ALTER USER
> PASSWORD case, there's INSERT INTO accounts(..., creditcardnumber,
> ...) VALUES(..., $n, ...). Neither one of those have a nearby UDF
> to control it with.
I was thinking incrementally ...
On Fri, May 29, 2020 at 3:26 PM Tom Lane wrote:
> One missing part of that is that we'd need to support bind parameters
> for utility statements, eg new password in ALTER USER. That's been
> on the wish list for a long time anyway, of course. I think it's
> mostly a matter of lack of round tuits
On Fri, May 29, 2020 at 3:05 PM Chapman Flack wrote:
> A possible step in the direction of good-enough would be to have
> 'sensitive' flags only in the parameter-bind message of the extended
> protocol.
Interesting idea. Changing the wire protocol for this sort of thing
makes it a much bigger lif
Chapman Flack writes:
> A possible step in the direction of good-enough would be to have
> 'sensitive' flags only in the parameter-bind message of the extended
> protocol.
Yeah, if we restrict our promises to being willing to not log (some)
bind parameters, that seems far more manageable, and rel
On 05/29/20 14:51, Robert Haas wrote:
> stuff that works today. We have options to log queries before parsing
> them. You can't redact sensitive details at that point because you
> don't know whether the query contains any such details, or where they
> are located. You can't postpone logging the qu
On Fri, May 29, 2020 at 12:38 PM Chapman Flack wrote:
> Just giving this thread a bump in honor of the mention of sensitive
> things in logs in the cryptography unconference session.
I agree that there's a problem here and I would like to see a solution
to it, too. Several EnterpriseDB customers
Just giving this thread a bump in honor of the mention of sensitive
things in logs in the cryptography unconference session.
I'm not partisan about any of the particular syntax examples I gave
earlier, but it seems like there were two key ingredients:
1. In what is sent from the client to the se
On 02/02/18 22:46, Tom Lane wrote:
> ... 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 o
On 3 February 2018 at 11:46, Tom Lane wrote:
> Chapman Flack 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 so
Chapman Flack 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 res
CREATE FUNCTION commence_primary_ignition(target text, password text)
RETURNS void AS ...;
SELECT commence_primary_ignition(target=>'Alderaan', password=>'1234');
/* 1234 could appear in logs, activity stats ... disturbing */
CREATE OR REPLACE FUNCTION commence_primary_ignition(
target tex
12 matches
Mail list logo
