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