KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> Tom Lane wrote:
>> This seems like a pretty bad idea that will eventually bite you in an
>> uncomfortable place. Lying about what datatype a field is is just not
>> safe.
> Is it also correct for system attributes?
> I don't think the format on storage has to be same as user visible one,
> because it always fetched via heap_getsysattr().
That's *exactly* the kind of thinking that will get you in trouble.
Where is it set in stone that system attributes are always fetched
via heap_getsysattr? In any case, this amounts to putting display
formatting of the value into heap_getsysattr, which surely seems
like the wrong place for it.
> In addition, all the route to import security attributes are hooked
> and translated it into oid correctly.
More of the same. It's only correct if you found and kluged up every
possible reference. If you were treating these things as a genuine data
type then you'd be working with the system structure, instead of having
to hack slash and burn to coerce it to do what you need.
> The prior version of SE-PostgreSQL has a similar idea.
> It is a specific type to translate security context between text
> and oid. But, it was opposed at CommitFest:May because its input
> handler has to insert a new tuple when the given security context
> is not found on pg_security.
Yeah, I do remember that discussion ... but an input handler with
side-effects seems better than what this solution is sounding like.
regards, tom lane
