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

From Dimitri Fontaine
Subject Re: [PATCH] Fix leaky VIEWs for RLS
Date
Msg-id m28w6v87yl.fsf@hi-media.com
Whole thread Raw
In response to Re: [PATCH] Fix leaky VIEWs for RLS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Fix leaky VIEWs for RLS
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> The proposal some time back in this thread was to trust all built-in
> functions and no others.  That's a bit simplistic, no doubt, but it
> seems to me to largely solve the performance problem and to do so with
> minimal effort.  When and if you get to a solution that's committable
> with respect to everything else, it might be time to think about
> more flexible answers to that particular point.

What about trusting all "internal" and "C" language function instead? My
understanding is that "internal" covers built-in functions, and as you
need to be a superuser to CREATE a "C" language function, surely you're
able to accept that by doing so you get to trust it?

How useful would that be?
-- 
dim


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: hot_standby = on
Next
From: Nikolay Samokhvalov
Date:
Subject: Re: rfc: changing documentation about xpath