pie-in-sky idea: 'sensitive' function parameters

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 text,
    password text SENSITIVE) RETURNS void AS ...;

SELECT commence_primary_ignition(target=>'Alderaan', password=>'1234');

/* logs, stats show something like ... password=>[redacted]); */


I had this idea while thinking about how to send a query with
some sensitive data in a way that would protect the data from
log exposure, and realizing I couldn't think of any. Docs for
log_statement even promise that extended query protocol Bind
parameters do get included. (But docs also suggested that some
minimal parsing occurs before log_statement happens, so there
could be an opportunity to detect that a sensitive parameter
is being mentioned and the extents of the assigned expression.)

I also appreciate that one doesn't want to empower a user to
conceal queries at will (thus track_activities and log_statement
are SUSET), which led me to the idea of a function parameter
declaration, putting the function definer in control of what
bits should get redacted.

In full generality, I'm sure this would present lots of
implementation challenges. But various restrictions might
possibly simplify it....

- recognize only in calls using named notation for the
  sensitive parameter(s)? (nothing to check for function
  calls using only positional notation)

- introduce a special named-notation variant?
  target=>'Alderaan', password=!>'1234'
  (no function lookup needed during parse, can identify what
  to redact immediately, and defer a simple check that 'password'
  really is declared sensitive to some later stage when function is
  looked up)

- recognize only in extended-protocol queries where the parameter
  is supplied by a Bind? (know what to redact without having to
  parse arbitrarily hairy expressions)


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?

-Chap