I am wondering whether we need to worry about leakproofness in connection
with adding in_range support functions to btree opclasses. My initial
conclusion is not, but let me lay out the reasoning so people can check
it --- I might be missing something.
The first question is whether we need to encourage in_range functions
to be leakproof. In the submitted patch, they mostly are not, because
they will happily blurt out the value of the "offset" argument if it's
negative, eg
if (offset < 0)
ereport(ERROR,
(errcode(ERRCODE_WINDOWING_ERROR),
errmsg("RANGE offsets cannot be negative. invalid value %d",
offset)));
(I'm not concerned here about whether this message text meets our style
guidelines, only about whether it should include the value of "offset".)
I think we could drop printing the value without a great deal of loss of
user-friendliness, although it is probably worth something. But there
are other cases that would be harder to prevent, for example an in_range
function might rely on a subtraction function that will complain on
overflow. So on the whole it'd be nicer if there were not a reason to
be concerned about leakiness of these functions.
The second question is whether there's even any need to worry about
leakproofness of support functions for window functions. Window function
calls are only allowed in a SELECT's target list and ORDER BY, not in
anything that could get pushed underneath a qual, so my first thought is
that we do not actually care. If we do care, there are weaknesses in this
area already, because contain_leaked_vars doesn't consider WindowFuncs at
all, let alone dig into the other support functions (such as equality)
that a WindowFunc node will use. But ISTM that's not an oversight, just
not bothering to write code that would be dead.
So I'm thinking that (a) we do not need to check for leaky functions used
in window support, and (b) therefore there's no need to avoid leaky
behavior in in_range support functions. Objections?
regards, tom lane
