From: | "Steve Howe" <howe(at)carcass(dot)dhs(dot)org> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Catalogs design question |
Date: | 2001-10-20 08:06:59 |
Message-ID: | 001d01c1593e$318c5790$8430b0c8@angla |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Bruce!
> 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?
About the groups: I just want to write a function that will return the users
names belonged by a given group. I understand I can load the arrays in
memory, then sequentially compare the members from pg_shadow, but doing it
goes against the database priciple after all.
About the procs: the Borland's dbExpress specification demands a
input/output list of parameters for stored procedures, and I'm going to use
functions as stored procedures. But I need to make a types list to be able
list what are those params.
> 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.
This design itself bothers me.
We have no other option left ? Like arrays being referenced in relations ?
That's far from perfect, but at least would solve those issues and others
which might appear in other catalogs...
Best Regards,
Steve Howe
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2001-10-20 08:26:08 | Re: Catalogs design question |
Previous Message | Steve Howe | 2001-10-20 07:55:45 | Re: Catalogs design question |