2012/1/21 Robert Haas <robertmhaas@gmail.com>:
> On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> I marked the default leakproof function according to the criteria that
>> does not leak contents of the argument.
>> Indeed, timestamp_ne_timestamptz() has a code path that rises
>> an error of "timestamp out of range" message. Is it a good idea to
>> avoid mark "leakproof" on these functions also?
>
> I think that anything which looks at the data and uses that as a basis
> for whether or not to throw an error is non-leakproof. Even if
> doesn't directly leak an arbitrary value, I think that leaking even
> some information about what the value is no good. Otherwise, you
> might imagine that we would allow /(int, int), because it only leaks
> in the second_arg = 0 case. And you might imagine we'd allow -(int,
> int) because it only leaks in the case where an overflow occurs. But
> of course the combination of the two allows writing something of the
> form 1/(a-constant) and getting it pushed down, and now you have the
> ability to probe for an arbitrary value. So I think it's just no good
> to allow any leaking at all: otherwise it'll be unclear how safe it
> really is, especially when combinations of different functions or
> operators are involved.
>
OK. I checked list of the default leakproof functions.
Functions that contains translation between date and timestamp(tz)
can raise an error depending on the supplied arguments.
Thus, I unmarked leakproof from them.
In addition, varstr_cmp() contains translation from UTF-8 to UTF-16 on
win32 platform; that may raise an error if string contains a character that
is unavailable to translate.
Although I'm not sure which case unavailable to translate between them,
it seems to me hit on the basis not to leak what kind of information is
no good. Thus, related operator functions of bpchar and text got unmarked.
(Note that bpchareq, bpcharne, texteq and textne don't use it.)
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
