Re: [PATCHES] aclitem accessor functions
Patch applied. Thanks. The oid's you chose were fine. I updated the system catalog version number, and added prototype for these functions. --- Fabien COELHO wrote: Dear patchers, Please find a attached a small patch that adds accessor functions for aclitem so that it is not an opaque datatype. I needed these functions to browse aclitems from user land. I can load them when necessary, but it seems to me that these accessors for a backend type belong to the backend, so I submit them. I wasn't sure of what oid should be given... I attributed new numbers at the end of pg_proc.h. It validates for me against current cvs head. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] aclitem accessor functions
The oid's you chose were fine. I updated the system catalog version number, and added prototype for these functions. Ok, in acl.h and catversion.h. I'm considering sending some patch for the documentation, although there is no real documentation about the aclitem type in the doc tree. Would 'func.sgml' next to has_*_privileges be an appropriate place? -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] aclitem accessor functions
Fabien COELHO wrote: The oid's you chose were fine. I updated the system catalog version number, and added prototype for these functions. Ok, in acl.h and catversion.h. Right. I'm considering sending some patch for the documentation, although there is no real documentation about the aclitem type in the doc tree. Would 'func.sgml' next to has_*_privileges be an appropriate place? Yes, I thought about that, but didn't see any existing stuff either. I assume folks who want it will do \df and poke around. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] aclitem accessor functions
Dear Peter, I needed these functions to browse aclitems from user land. I can load them when necessary, but it seems to me that these accessors for a backend type belong to the backend, so I submit them. Can you explain what you want to do from the user level? Sure. Before developing that point, I want to underline that it should be a general principle to avoid opaque datatypes in pg that stores structured information without being able to access them directly. Either you trust the database as a general tool, and it can manipulate its own data, or you do no trust it and you want any special system thing to be programmed in C or whatever instead of queried from SQL. As for the specifics: I'm developing some pg_advisor schema that was discussed earlier, so as to check the design, performance, system... coherency of a database. This is developed in userland with simple relational queries on pg_catalog, and some help by plpgsql if I cannot do without it. Among many other things, I would like to check that granted rights are granted by grantors who have a with grant option, for all possible objects and users. We already have a bunch of functions for analyzing privileges. Sure, but these has_privilege functions answer to specific questions. I could do that with these functions, but they hide queries, and I think that some joins would be enough to get all the answers directly without sub-quering for all possible object and user. I order to do so, I need to be able to read the aclitem type, so I added these accessors. The patch just adds 5 2-lines C functions. Have a nice day, -- Fabien. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] aclitem accessor functions
Dear patchers,
Please find a attached a small patch that adds accessor functions
for aclitem so that it is not an opaque datatype.
I needed these functions to browse aclitems from user land. I can load
them when necessary, but it seems to me that these accessors for a backend
type belong to the backend, so I submit them.
I wasn't sure of what oid should be given...
I attributed new numbers at the end of pg_proc.h.
It validates for me against current cvs head.
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]*** ./src/backend/utils/adt/acl.c.orig Sat Nov 29 20:51:57 2003
--- ./src/backend/utils/adt/acl.c Mon Apr 12 15:23:17 2004
***
*** 874,879
--- 874,916
PG_RETURN_ACLITEM_P(aclitem);
}
+ /* give access to internal data within aclitem
+ */
+ Datum
+ aclitem_grantee(PG_FUNCTION_ARGS)
+ {
+ AclItem * a = PG_GETARG_ACLITEM_P(0);
+ PG_RETURN_INT32(a-ai_grantee);
+ }
+
+ Datum
+ aclitem_grantor(PG_FUNCTION_ARGS)
+ {
+ AclItem * a = PG_GETARG_ACLITEM_P(0);
+ PG_RETURN_INT32(a-ai_grantor);
+ }
+
+ Datum
+ aclitem_idtype(PG_FUNCTION_ARGS)
+ {
+ AclItem * a = PG_GETARG_ACLITEM_P(0);
+ PG_RETURN_INT32(ACLITEM_GET_IDTYPE(*a));
+ }
+
+ Datum
+ aclitem_privs(PG_FUNCTION_ARGS)
+ {
+ AclItem * a = PG_GETARG_ACLITEM_P(0);
+ PG_RETURN_INT32(ACLITEM_GET_PRIVS(*a));
+ }
+
+ Datum
+ aclitem_goptions(PG_FUNCTION_ARGS)
+ {
+ AclItem * a = PG_GETARG_ACLITEM_P(0);
+ PG_RETURN_INT32(ACLITEM_GET_GOPTIONS(*a));
+ }
+
static AclMode
convert_priv_string(text *priv_type_text)
{
*** ./src/include/catalog/pg_proc.h.origMon Apr 5 12:06:43 2004
--- ./src/include/catalog/pg_proc.h Mon Apr 12 16:54:52 2004
***
*** 3526,3531
--- 3526,3543
DATA(insert OID = 1069 ( generate_series PGNSP PGUID 12 f f t t v 2 20 20 20
_null_ generate_series_int8 - _null_ ));
DESCR(non-persistent series generator);
+ /* aclitem utils */
+ DATA(insert OID = 2510 ( aclitem_grantorPGNSP PGUID 12 f f
t f i 1 23 1033 _null_ aclitem_grantor - _null_ ));
+ DESCR(extract user id grantor from aclitem);
+ DATA(insert OID = 2511 ( aclitem_granteePGNSP PGUID 12 f f
t f i 1 23 1033 _null_ aclitem_grantee - _null_ ));
+ DESCR(extract grantee (user or group id) from aclitem);
+ DATA(insert OID = 2512 ( aclitem_idtype PGNSP PGUID 12 f f
t f i 1 23 1033 _null_ aclitem_idtype - _null_ ));
+ DESCR(extract id type of grantee (0 public, 1 user, 2 group) from aclitem);
+ DATA(insert OID = 2513 ( aclitem_privs PGNSP PGUID 12 f f
t f i 1 23 1033 _null_ aclitem_privs - _null_ ));
+ DESCR(extract privileges from aclitem);
+ DATA(insert OID = 2514 ( aclitem_goptions PGNSP PGUID 12 f f
t f i 1 23 1033 _null_ aclitem_goptions - _null_ ));
+ DESCR(extract grant options from aclitem);
+
/*
* Symbolic values for provolatile column: these indicate whether the result
*** ./src/test/regress/expected/privileges.out.orig Mon Sep 15 02:26:31 2003
--- ./src/test/regress/expected/privileges.out Mon Apr 12 16:51:00 2004
***
*** 581,586
--- 581,600
t
(1 row)
+ -- aclitem utils small test
+ SELECT u1.usename AS u1, u2.usename AS u2,
+ aclitem_idtype(c.relacl[0]) AS idtype,
+ aclitem_privs(c.relacl[0]) AS privs,
+ aclitem_goptions(c.relacl[0]) AS goptions
+ FROM pg_class AS c, pg_user AS u1, pg_user AS u2
+ WHERE u1.usesysid = aclitem_grantor(c.relacl[0])
+ AND u2.usesysid = aclitem_grantee(c.relacl[0])
+ AND c.relname LIKE 'atest4';
+ u1 | u2 | idtype | privs | goptions
+ --+--++---+--
+ regressuser1 | regressuser1 | 1 | 127 | 127
+ (1 row)
+
-- clean up
\c regression
DROP FUNCTION testfunc2(int);
*** ./src/test/regress/sql/privileges.sql.orig Wed May 14 05:26:03 2003
--- ./src/test/regress/sql/privileges.sql Mon Apr 12 16:49:48 2004
***
*** 316,321
--- 316,330
SELECT has_table_privilege('regressuser1', 'atest4', 'SELECT WITH GRANT OPTION'); --
true
+ -- aclitem utils small test
+ SELECT u1.usename AS u1, u2.usename AS u2,
+ aclitem_idtype(c.relacl[0]) AS idtype,
+ aclitem_privs(c.relacl[0]) AS privs,
+ aclitem_goptions(c.relacl[0]) AS goptions
+ FROM pg_class AS c, pg_user AS u1, pg_user AS u2
+ WHERE u1.usesysid = aclitem_grantor(c.relacl[0])
+ AND u2.usesysid = aclitem_grantee(c.relacl[0])
+ AND c.relname LIKE 'atest4';
-- clean up
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] aclitem accessor functions
Fabien COELHO wrote: Please find a attached a small patch that adds accessor functions for aclitem so that it is not an opaque datatype. I needed these functions to browse aclitems from user land. I can load them when necessary, but it seems to me that these accessors for a backend type belong to the backend, so I submit them. Can you explain what you want to do from the user level? We already have a bunch of functions for analyzing privileges. ---(end of broadcast)--- TIP 8: explain analyze is your friend
