Robert Haas wrote:
>>> IANAC, but that's my impression too. The simplified patch shouldn't
>>> assume that row-level security in its current form is going to end up
>>> getting put back in. AFAICS, there's no reason why the security ID
>>> for tables can't be a regular attribute in pg_class, or why the
>>> security attribute for columns can't be a regular attribute in
>>> pg_attribute.
>> If it is "identifier", it can be compoundable.
>>
>> I dislike it is held as "text". It fundamentaly breaks SE-PostgreSQL's
>> architecture, and requires to scrap near future.
>
> I think the column in pg_attribute and pg_class can and should be an
> OID. The issue is whether it's a regular OID column or a new system
> column. Stephen and I are saying it should be a regular column.
> pg_security can stick around to map OIDs to text labels.
OK, I accept to omit a facility to save security id on padding field
of HeapTupleHeader *in this step*, if is has no other matter unexpected.
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
