Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)

On Sun, Jan 22, 2012 at 5:12 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2012/1/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sat, Jan 21, 2012 at 3:59 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company