Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)

> Here is one another idea.
> How do you think asymmetric input/output handlers?
>
> At first, I have to introduce the current implementation.
> It can receives user input values as TEXT or ACLITEM[], ant these are
> fetched at fetchWritableSystemAttribute() on execMain.c.
> Please note that they have no side-effect on the prior stage.
> Then, it invokes rowaclSecurityAclToSid() or pgaceSecurityLabelToSid()
> to translate the values into security identifier. These functions can
> insert a new tuple into pg_security, if not found.
> Then, the translated security identifiers are set on the HeapTupleHeader
> using HeapTupleSetRowAcl() or HeapTupleSetSecLabel().
>
> If the input handler is asymmetric, it can handle the given user input
> as a TEXT or ACLITEM[], and can deliver them fetchWritableSystemAttribute()
> as is. But asymmetric output handler can translate given security
> identifier
> into proper user visible data.

I noticed the asymmetric input/output handler will break something
when someone declares user-columns as the type with asymmetric handlers.
Please forget it.

> However, I don't think it is a fair enough solution. :(
> The current implementation seems to me better.

Maybe, we need to consider what data type should be fetched via
system column. Previously, it returns required identifier of tuple,
like oid and tableoid, as is, because raw-data format is matched
with requirement for user interfaces, fortunatelly.
However, is it possible to consider the system column returns
a proper metadata virtually generated based on the given tuple's
attributes?

I don't intend to convert security id to security label here for
cosmetic purpose. It has to be done here, because "security_label"
is a TEXT data generated on runtime.

It is not an issue on implementation, an issue in frame of thinking.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>