Re: Binary in/out for aclitem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rsmogura <rsmogura(at)softperience(dot)eu>
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 15:19:27
Message-ID: 28636.1298474367@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-02-23 15:22:14 Re: Correctly producing array literals for prepared statements
Previous Message Andrew Dunstan 2011-02-23 15:16:32 Re: Correctly producing array literals for prepared statements