Re: Catalogs design question

From: Haller Christoph <ch(at)rodos(dot)fzk(dot)de>
To: howe(at)carcass(dot)dhs(dot)org (Steve Howe)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Catalogs design question
Date: 2001-10-22 17:13:57
Message-ID: 200110221513.RAA18694@rodos
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-10-22 17:22:27 Re: [GENERAL] To Postgres Devs : Wouldn't changing the select limit
Previous Message Bruce Momjian 2001-10-22 17:00:15 Re: [GENERAL] To Postgres Devs : Wouldn't changing the select limit