Re: [0/4] Proposal of SE-PostgreSQL patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches
Date: 2008-05-12 14:30:13
Message-ID: 19287.1210602613@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> Tom Lane wrote:
>> Yeah, I remember those. What needs to be looked at here is *why* the
>> output is changing. For a patch that allegedly does not touch the
>> planner, it's fairly disturbing that you don't get the same results.

> SE-PostgreSQL does not touch the planner, but it modifies given query
> to filter violated tuples for the current user.

Hmm. Is that really a good idea, compared to hard-wiring the checks
into nodeSeqscan and friends? I didn't look at the query-rewriting
portion of the patch in any detail, but I'd tend not to trust such
a technique very far: getting it right is going to be quite complex
and probably bug prone.

>> Are you sure that the security_label type should not have an array type?

> Yes, security_label type should not have an array type.

You didn't provide one ounce of justification for making it not obey the
expected behavior, so I'm not accepting this position. It doesn't seem
to me to be all that unlikely that users would want to compute with
arrays of security labels. As an example:
select ... where security_label in ('foo', 'bar')
which will become an = ANY(ARRAY[]) construct under the hood.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-12 14:37:20 Re: pgsql: Convert wal_sync_method to guc enum.
Previous Message Andrew Dunstan 2008-05-12 14:28:43 Re: constraint exclusion analysis caching

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2008-05-12 14:45:55 Re: [0/4] Proposal of SE-PostgreSQL patches
Previous Message Pavel Stehule 2008-05-12 07:29:56 Re: options for RAISE statement