Robert Haas <robertmhaas@gmail.com> writes:
> Checking the functions of the operators is the right thing to do, but
> assuming that internal = safe does not work. For example, pushing
> down arithmetic operators allows you to probe for any given value in a
> hidden row by testing whether 1 / (x - constant) throws a division by
> zero error.
Well, if the goal is "make it impossible to tell whether such-and-such a
value exists", I think this approach can't meet it at all. There are
too many side channels. You're focusing here on the error-report side
channel, but there's also performance, ie how long did the query take.
(BTW, is the intent to somehow lobotomize EXPLAIN so you can't use that
to see what happened?)
Personally I think this is a dead end that we shouldn't be wasting
any more time on.
> Doesn't sound bad, but I just had another thought. How about defining
> a new relkind? It'll make the patch a little more complex but I think
> if it avoids adding a column to pg_class it's probably worth it.
New relkind would make the patch affect a lot of stuff that shouldn't
need to care, including client-side code.
regards, tom lane
