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