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

KaiGai Kohei  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