> Text represented security attribute is the most common format > for any other security mechanism also. > (For example, T-SOL also have its text representation.) > In addition, TEXT is the most flexible format. If any other > feature want to handle it as an array, it can be stored as > a text representation.
Right, but that sort of misses the point of using a DATABASE. I could store everything as text if I wanted to and skip using a database altogether, but I don't want to. That's why I use a database. > Please make clear the meaning of terms. > The 'plugin' means a loadable module which provides its own security > policy, doesn't it? That is what I meant, yes. > Even if I implement SE-PostgreSQL as a loadable module, core > PostgreSQL has to provide proper hooks in strategic points and > facilities to manage security attribute (pg_security system catalog > and security_label system column). > If you require to implement it without these facilities, I think > it is impossible and prefer scraping PGACE and integrate SE- code > into core. I am not in a position to require anything since I am not a committer, but I would think that you would need to convince people that the facilities which your plugin requires were pretty much the same as the facilities that any other future plugin might require - that the plugin framework was client-agnostic. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
