2010/7/23 KaiGai Kohei <kaigai@ak.jp.nec.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