Re: Binary in/out for aclitem

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> Wednesday 23 February 2011 16:19:27
> rsmogura <rsmogura(at)softperience(dot)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

Actully, You litlle messed in my head. So in prev post we don't need to send
information if grant option has been set, currently in text mode no grant
options means ACL_NO_RIGHTS, and in binary same may be achived be settig there
0.

But version field may be usefull to validate this and future calls, and
provide backward compatibility (if newer client will send less bits then rest
of bits will be set to 0).

I think about splitting privs chain to two numbers, it may be easier to
implement this and parse if number of privs will extend 32...

In addition I may add support for possible, future representation, where given
privilige may be yes, no, undefined (like in Windows).

Regrads,
Radek