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

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Kohei(dot)Kaigai(at)emea(dot)nec(dot)com, thom(at)linux(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [v9.2] LEAKPROOF attribute of FUNCTION (Re: [v9.2] Fix Leaky View Problem)
Date: 2012-01-26 10:19:49
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

2012/1/25 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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.
OK, the attached one is the rebased one.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Attachment Content-Type Size
pgsql-v9.2-leakproof-function.v4.patch.gz application/x-gzip 76.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Reykja 2012-01-26 10:43:40 Re: Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
Previous Message Fujii Masao 2012-01-26 09:19:28 Re: xlog location arithmetic