| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | peter_e(at)gmx(dot)net (Peter Eisentraut) |
| Cc: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: type design guidance needed |
| Date: | 2000-09-23 16:37:49 |
| Message-ID: | 1773.969727069@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Bruce, is that the case? Do you really have it documented? If so,
>> where?
> src/backend/utils/cache/syscache.c
BTW, it occurs to me that the real reason adding a syscache is invasive
is that the syscache routines accept parameters that are integer indexes
into syscache.c's cacheinfo[] array. So there's no way to add a
syscache without changing this file. But suppose that the routines
instead accepted pointers to cachedesc structs. Then an add-on module
could define its own syscache without ever touching syscache.c. This
wouldn't even take any widespread code change, just change what the
macros AGGNAME &etc expand to...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-09-24 00:03:56 | psql's \d functions broken for views in current sources |
| Previous Message | Bernard Frankpitt | 2000-09-23 15:59:01 | Re: type design guidance needed |