From: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Binary in/out for aclitem |
Date: | 2011-02-23 16:07:32 |
Message-ID: | 201102231707.32587.rsmogura@softperience.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
I removed from patch this (think like currently not needed, but it is enaught
to put in doc)
Each privilige has idividual number P from 1 to n. and it is represented by
setted P-th bit. First n-th bits (in network bit order) represents normal
priv, next n-th bits represents grant option of privs. This "chain" is encoded
as n*2 bit number rounded up to full 8 bits, with minimal length 32 bit.
I was thinking about adding number of all privs to each ACL item, removed as
this could be deducted from PG version, where 1st 7-bit represents version,
last 8-th bit will represent if grant part has been added.
---
In any way binary output should be available, if we have binary mode. I know
that text is more extensible, we may in contrast to above "packed" version,
describes acl privs as byte array elements from represented setted priv (same
as text).
Fallback solution is to just recall aclin/aclout with StringInfo.
Regards,
Radek.
From | Date | Subject | |
---|---|---|---|
Next Message | Radosław Smogura | 2011-02-23 16:35:08 | Re: Binary in/out for aclitem |
Previous Message | Peter Eisentraut | 2011-02-23 15:44:01 | Re: pl/python quoting functions |