Re: Catalogs design question

Yes, we inherited these arrays from Berkeley and haven't had any need to
remove them. Are you trying to do things that the other interfaces like
ODBC and JDBC don't handle?

The group array is a hack but the pg_proc array would be hard to replace
becauseit acts as part of the unique key used for cache lookups.

---------------------------------------------------------------------------

> Hello all!!
>
>
> I'm developer of a interface for PostgreSQL for the Borland Kylix
> and Delphi tools (http://www.vitavoom.com). I've run into the following
> problems with catalogs:
>
> - pg_group: the grolist field is an array. How can I make a query
> that tell me the usernames of a group ?
> - pg_proc: the proargtypes field is an array. How can I make a query
> that will link those types to the pg_types catalog ???
>
> This catalog design seems a very crude hack to make the things
> working for me. Can't those relations be separated in another table ? Or
> maybe a function that can search for a value in array, and make a wroking
> reference for an array
> element in a relation (something like "select typname from pg_type, pg_group
> where oid
> in grolist").
> I also quote the PotgreSQL user manual
> (http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/arrays.html):
>
> "Tip: Arrays are not lists; using arrays in the manner described in the
> previous paragraph is often a sign of database misdesign. The array field
> should generally be split off into a separate table. Tables can obviously be
> searched easily."
>
> Best Regards,
> Steve Howe
>
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026