Re: Binary in/out for aclitem

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 01:47:55
Message-ID: AANLkTimNOkPiA2cRLQAZi=QVjE2kynqqf-=gv+FLAGFc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ removing Radoslaw from the CC list, as his email is bouncing every time ]

On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Well, unfortunately, there's an awful lot of information that can only
be obtained in a reasonable way by introspection of the system
catalogs. If you want to know whether user A can select from table B,
there's really no sensible way of obtaining that without parsing the
aclitem entries in some fashion, and unfortunately that's just the tip
of the iceberg. One of the first applications I wrote for PG included
a tool to upgrade the production schema to match the dev schema, which
promptly got broken when (I'm dating myself here[1]) PG added support
for dropping columns (7.3) and recording the grantor on aclitems
(7.4). I'm not going to claim that there aren't better ways of trying
to solve the problems that I was trying to solve that day, but at the
time it seemed like the best solution, and if I had a dollar for every
other person who is written a similar application, I am pretty sure I
could afford at least a pizza, if not dinner at Fogo de Chao.

Now, if you were to propose adding a well-designed set of DCL commands
to expose this kind of information to clients in a more structured
way, I would be the first to applaud. LIST TABLES? SHOW GRANTS TO?
Sign me up! (I got a request for the latter just today.) But until
then, if you need this information, you don't have much choice but to
pull it out of the system catalogs; and if JDBC would rather use
binary format to talk to the server, I don't particularly see any
reason to say "no". If we prefer to expose the text format rather
than anything else, that's OK with me, but I do think it would make
sense to expose something.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] Insert obligatory joke about how no one else would.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Ports 2011-02-23 01:49:51 Re: SSI bug?
Previous Message Itagaki Takahiro 2011-02-23 01:42:16 psql tab-completion for CREATE UNLOGGED TABLE