Re: security label support, part.2

2010/7/23 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> Hmm.  How about if there's just one provider loaded, you can omit it,
>> but if you fail to specify it and there's>1 loaded, we just throw an
>> error saying you didn't specify whose label it is.
>>
> Perhaps, we need to return the caller a state whether one provider checked
> the given label at least, or not.

Return to the caller? This is an SQL command. You either get an
error, or you don't.

> If it was omitted, all the providers try to check the given label, but it
> has mutually different format, so one of providers will raise an error at
> least.

Yeah, but it won't be a very clear error, and what if you have, say, a
provider that allows arbitrary strings as labels? Since this is a
security feature, I think it's a pretty bad idea to allow the user to
do anything that might be ambiguous.

> It means we have to specify the provider when two or more providers are
> loaded, but not necessary when just one provider.

But that should be fine. Loading multiple providers should, as you
say, be fairly rare.

>>>> I think it is 100% clear that row-level security will require
>>>> completely separate infrastructure, and therefore I'm not even a tiny
>>>> bit worried about this.  :-)
>>>>
>>> Hmm. Are you saying we may degrade the feature when we switch to the
>>> completely separate infrastructure? Is it preferable??
>>
>> Uh... no, not really.  I'm saying that I don't think we're backing
>> ourselves into a corner.  What makes you think we are?
>>
> Sorry, meaning of the last question was unclear for me.... Is it a idiom?

I don't understand why we wouldn't be able to support multiple
providers for row-level security. Why do you think that's a problem?

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