Re: Catalogs design question
От | Haller Christoph |
---|---|
Тема | Re: Catalogs design question |
Дата | |
Msg-id | 200110221513.RAA18694@rodos обсуждение исходный текст |
Ответ на | Re: Catalogs design question ("Steve Howe" <howe@carcass.dhs.org>) |
Список | pgsql-hackers |
Hi Steve, Your question about - pg_proc select t.typname from pg_type t , pg_proc p where p.proname = '<your_stored_procedure>' and p.proargtypes[0] = t.oid ; select t.typname from pg_type t , pg_proc p where p.proname = '<your_stored_procedure>' and p.proargtypes[1] = t.oid ; ... select t.typname from pg_type t , pg_proc p where p.proname = '<your_stored_procedure>' and p.proargtypes[7] = t.oid ; As far as I understand the proargtypes entries 0 means no further parameter. This oidvector type of proargtypes seems to have a start index of 0. As long as there are at maximum 8 parameters allowed, this looks practicable. Your question about - pg_group The pg_group column is more bulky, because the int4[] type does not have an upper limit. So, the only solution I can see is get the number of array elements of the group you want to query select array_dims(grolist) from pg_group where groname = '<your_group>'; and then generate automatically a query like select u.usename from pg_user u , pg_group g where g.grolist[1] = u.usesysid and g.groname='<your_group>' union select u.usename from pg_user u , pg_group g where g.grolist[2] = u.usesysid and g.groname='<your_group>' union ... select u.usename from pg_user u , pg_group g where g.grolist[n] = u.usesysid and g.groname='<your_group>' ; This looks very much like another crude hack you've already complained about. Sorry, but I can't help. Two more items I do not understand: You said, the procedures to search arrays in contrib/ are slow. Maybe that's true, but usually you do not have thousands of users in a group, don't you. You said, many users cannot compile this contrib code. Yes, and they are not supposed to do so, because it's up to a system admin to do. What do I miss here? Regards, Christoph
В списке pgsql-hackers по дате отправления: