On Thu, 28 Feb 2019 at 14:13, Robert Haas <robertmh...@gmail.com> wrote: > A wild idea might be to let > proleakproof take on three values: yes, no, and maybe. When 'maybe' > functions are involved, we tell them whether or not the current query > involves any security barriers, and if so they self-censor. >
Does self-censoring mean that they might still throw an error for some inputs, but that error won't reveal any information about the input values? That's not entirely consistent with my understanding of the definition of leakproof, but maybe there are situations where that amount of information leakage would be OK. So maybe we could have "strictly leakproof" functions that never throw errors and "weakly leakproof" functions (needs a better name) that can throw errors, as long as those errors don't include data values. Then we could allow strict and weak security barriers on a per-table basis, depending on how sensitive the data is in each table (I'm not a fan of using GUCs to control this). Regards, Dean
