Re: SECURITY LABEL on shared database object

The attached patch re-defines pg_shseclabel.provider as NameData,
instead of Text,
and revert changes to catcache.c about collation.

Rest of parts are not changed.

Thanks,

2011/7/2 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> 2011/7/2 Tom Lane <tgl@sss.pgh.pa.us>:
>> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>>> The origin of matter is, as you mentioned, collation to be used for system
>>> catalog scan when we reference it via syscache.
>>> So, the following chunk should be added, as I did in the userspace access
>>> vector patch - part.1.
>>
>>>   @@ -934,8 +935,7 @@ CatalogCacheInitializeCache(CatCache *cache)
>>>           /* Fill in sk_strategy as well --- always standard equality */
>>>           cache->cc_skey[i].sk_strategy = BTEqualStrategyNumber;
>>>           cache->cc_skey[i].sk_subtype = InvalidOid;
>>>   -       /* Currently, there are no catcaches on collation-aware data types */
>>>   -       cache->cc_skey[i].sk_collation = InvalidOid;
>>>   +       cache->cc_skey[i].sk_collation = DEFAULT_COLLATION_OID;
>>
>> I removed such a hunk from a previous patch of yours, and I don't like
>> it any better this time.  This is just a hack that will result in
>> masking bugs.
>>
>> Consider using a non-collation-aware datatype instead, such as NAME.
>>
> I agree that pg_(sh)seclabel.provider field shall not need more than
> NAMEDATALEN.
>
> How about re-define pg_seclabel.provider field also; currently defined as TEXT?
>
> Thanks,
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>
>
--
KaiGai Kohei <kaigai@kaigai.gr.jp>