Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
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-21 17:00:26
Message-ID: CA+TgmoZ+MmrDwq0DH9igbB8oVFU-pZmjKAhLTgnaA1WTschZYg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

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

In response to

Responses

pgsql-hackers by date

Next:From: Tomas VondraDate: 2012-01-21 17:02:01
Subject: Re: PATCH: tracking temp files in pg_stat_database
Previous:From: Euler Taveira de OliveiraDate: 2012-01-21 16:13:41
Subject: Re: xlog location arithmetic

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group