2012/1/26 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> 2012/1/25 Robert Haas <robertmhaas@gmail.com>:
>> On Sun, Jan 22, 2012 at 5:12 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>> 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.)
>>
>> Can you rebase this? It seems that the pg_proc.h and
>> select_views{,_1}.out hunks no longer apply cleanly.
>>
> OK, the attached one is the rebased one.
>
I rebased the patch due to the updates of pg_proc.h.
Please see the newer one. Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>