rsmogura <rsmog...@softperience.eu> writes:
> On Tue, 22 Feb 2011 20:20:39 -0500, Tom Lane wrote:
>> ... But my question isn't about that; it's about
>> why aclitem should be considered a first-class citizen. It makes me
>> uncomfortable that client apps are looking at it at all, because any
>> that do are bound to get broken in the future, even assuming that
>> they get the right answers today. I wonder how many such clients are up
>> to speed for per-column privileges and non-constant default privileges
>> for instance. And sepgsql is going to cut them off at the knees.
> Technically, at eye glance, I didn't seen in sepgsql modifications to
> acl.h. So, I think, aclitem will be unaffected. In any way sepgsql needs
> some way to present access rights to administrator it may use own model,
> or aclitem, too.
You're missing the point, which is that the current internal
representation of aclitem could change drastically to support future
feature improvements in the area of privileges. It has already changed
significantly in the past (we didn't use to have WITH GRANT OPTION).
If we had to add a field, for instance, a binary representation would
simply be broken, as clients would have difficulty telling how to
interpret it as soon as there was more than one possible format.
Text representations are typically a bit more extensible.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
