Re: Catalogs design question - Mailing list pgsql-hackers

From Haller Christoph
Subject Re: Catalogs design question
Date
Msg-id 200110221513.RAA18694@rodos
Whole thread Raw
In response to Re: Catalogs design question  ("Steve Howe" <howe@carcass.dhs.org>)
List 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 by date:

Previous
From: Christof Petig
Date:
Subject: HISTORY (ecpg enhancements not yet mentioned)
Next
From: speedboy
Date:
Subject: createlang difficulty.