Re: [PATCH] Fix leaky VIEWs for RLS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Fix leaky VIEWs for RLS
Date
Msg-id 2629.1275662037@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Fix leaky VIEWs for RLS  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [PATCH] Fix leaky VIEWs for RLS  (Marc Munro <marc@bloodnok.com>)
Re: [PATCH] Fix leaky VIEWs for RLS  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 04/06/10 07:57, Tom Lane wrote:
>> The proposal some time back in this thread was to trust all built-in
>> functions and no others.

> I thought I debunked that idea already 
> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php). Not 
> all built-in functions are safe. Consider casting integer to text, for 
> example. Seems innocent at first glance, but it's not; if the input is 
> not a valid integer, it throws an error which contains the input string, 
> revealing it.

Hmm ... that's a mighty interesting example, because it shows that any
well-meaning change in error handling might render seemingly-unrelated
functions "unsafe".  And we're certainly not going to make error
messages stop showing relevant information just because of this.

Maybe the entire idea is unworkable.  I certainly don't find any comfort
in your proposal in the above-referenced message to trust index
operators; where is it written that those don't throw errors?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Next
From: Greg Stark
Date:
Subject: Re: Exposing the Xact commit order to the user