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

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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