On Tue, 22 Feb 2011 20:20:39 -0500, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
It'd be more future-proof than this patch, but I'm still
unconvinced
about the use-case.
Do we want to intentionally make binary format a second-class
citizen?
Well, it's not exactly a first-class citizen; compare for instance
the
amount of verbiage in the docs about text I/O formats versus the
amount
about binary formats. 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.
regards, tom lane
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.
JDBC, and other applications may use aclitem to get just information
about who has what access. I think psql does this in same manner as
JDBC, by calling select from pg_class. But if user, through psql, JDBC
or other driver. will invoke "select * from pg_class" it will fail with
"no binary output", because it is plain user query.
Currently proposed binary output has space for 4 more privs. Am I
right?
One thing I realized, I do not pass flag if grant target is group or
user.
Regards,
Radek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
