"Greg Smith" <gsmith@[EMAIL PROTECTED]
> writes:
> The approach taken here is to put all the "#ifdef" logic into the
underlying
> ACE interface (see patch [2/4]), so that the caller doesn't have to
care. If
> SELinux sup****t is off then the calls turns into
>
> void x(y) {} or
> bool a(b) { return true; }
>
> This is a very clean design, but it's putting extra (possibly optimized
away)
> calls into a lot of places. While it would be uglier, it might make
sense to
> put that on/off logic in all the places where the calls are made, so
that when
> you turn SELinux sup****t off most of the code really does go completely
away
> rather than just turning into stubs.
It's nicer to do it the way they have but we don't generally trust
compilers
to inline functions. Is it hard to make those functions into macros?
> -The only error re****ting and handling method used is "elog(ERROR,...".
That
> seems a bit heavy handed for something that can be expected to happen
all the
> time.
>
> If I understand this correctly, when you're scanning a table with 1000
rows
> where you're only allowed to see 50% of them, that's going to be 500
call to
> elog(), one for each tuple you can't see. Having a tuple get screened
out
> isn't really an error per se, and while I can see how sensitive installs
would
> want those all re****ted there are others where this volume of log
activity
> would be too much. Just because someone with classified clearance is
looking
> at a big table that also has a lot of secret info in it, not all
installs will
> want a million errors re****ted just because there's data that person
can't see
> available.
I don't understand, if it's ERROR it would throw an error and stop the
current
query. Or is this all within a PG_TRY() ?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
