From: | alvherre <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mapping object names to role IDs |
Date: | 2010-05-26 19:02:57 |
Message-ID: | 1274900345-sup-9420@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Robert Haas's message of mié may 26 10:34:00 -0400 2010:
> lsyscache.c might have no conceptual consistency but it's extremely
> useful,
I know I've been annoyed by lsyscache: looking for accessors to catalog
stuff, not finding them and so creating my own by using syscache
directly, only to find out later that they already existed there.
I think we should be moving in the direction of *removing* lsyscache,
not replicating it.
BTW I quite agree with both the suggestion you give in this thread
(modulo this issue), and Peter's idea of getting rid of the repetitive
syscache coding pattern.
> and there are
> plenty of other examples of where we've put code for different object
> types into a single file to simplify maintenance and reduce code
> complexity (e.g. copyfuncs, equalfuncs, outfuncs, etc.).
Well, that's all related to node manipulation, so I'm not so sure it's
exactly the same.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-05-26 19:13:31 | Re: Synchronization levels in SR |
Previous Message | Robert Haas | 2010-05-26 18:57:29 | Re: mapping object names to role IDs |