Re: Binary in/out for aclitem

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.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             | baclitem          | bgtsvector        | bany              | ptrigger
    | planguage_handler | pinternal         | popaque           | panyelement       | panynonarray      | panyenum
   | pfdw_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