Re: Binary in/out for aclitem

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

> 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.

Um, that question is precisely why we invented the has_foo_privilege
class of functions. I would *much* rather see users applying those
functions than looking at ACLs directly --- and if there's some
reasonable use-case that those don't cover, let's talk about that.

> 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.

Well, to go back to the binary-format issue, if we're going to insist
that all standard types have binary I/O support then we should actually
do that, not accept piecemeal patches that move us incrementally in that
direction without establishing a policy. To my mind, "establishing a
policy" would include adding a type_sanity regression test query that
shows there are no missing binary I/O functions. As of HEAD, we have

postgres=# select typname,typtype from pg_type where typreceive = 0 or typsend = 0;
typname | typtype
------------------+---------
smgr | b
aclitem | b
gtsvector | b
any | p
trigger | p
language_handler | p
internal | p
opaque | p
anyelement | p
anynonarray | p
anyenum | p
fdw_handler | p
(12 rows)

Possibly we could exclude pseudotypes from the policy, on the grounds
there are never really values of those types anyway. But other than
that, we have:

smgr: let's just get rid of that useless vestigial type.

aclitem: as per this thread, using the text representation as
the binary representation seems reasonable, or at least it doesn't
make anything any worse.

gtsvector: this is strictly an internal type, so it probably
doesn't need actual I/O support, but we could put in a couple of
dummy functions that just throw ERRCODE_FEATURE_NOT_SUPPORTED.

Maybe the right plan would be to give all the pseudotypes error-throwing
binary I/O functions too. Then, if anyone lobbies for not throwing an
error (as per what we just did with "void"), at least it doesn't take
a catversion bump to fix it.

If someone wanted to propose doing all that, I could get behind it.
But I'm not excited about debating this one datatype at a time.

regards, tom lane