Re: SECURITY LABEL on shared database object

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>