Robert Haas <robertmh...@gmail.com> writes: > On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane <t...@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 | 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers