Re: Binary in/out for aclitem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Binary in/out for aclitem
Дата
Msg-id 28636.1298474367@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Binary in/out for aclitem  (rsmogura <rsmogura@softperience.eu>)
Ответы Re: Binary in/out for aclitem  (Radosław Smogura <rsmogura@softperience.eu>)
Re: Binary in/out for aclitem  (Radosław Smogura <rsmogura@softperience.eu>)
Re: Binary in/out for aclitem  (Radosław Smogura <rsmogura@softperience.eu>)
Список pgsql-hackers
rsmogura <rsmogura@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Correctly producing array literals for prepared statements
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Correctly producing array literals for prepared statements