|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Binary in/out for aclitem|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
|Next Message||Robert Haas||2011-02-23 02:43:53||Re: Binary in/out for aclitem|
|Previous Message||Robert Haas||2011-02-23 02:22:10||Re: Why we don't want hints Was: Slow count(*) again...|