mapping object names to role IDs
in [PgSql]
|
From: Tom Lane on 26 May 2010 13:27 alvherre <alvherre(a)commandprompt.com> writes: > Excerpts from Robert Haas's message of mié may 26 07:20:30 -0400 2010: >> I still feel that we'd be better off putting all the functions that >> use the same design pattern in a single file, rather than spreading >> them out all over the backend. > This doesn't buy you anything, because that one header will likely have > to #include all the other headers anyway. And if this is so, then all > those headers will now be included in all files that require even a > single one of these functions. For the particular case Robert is proposing, the *header* isn't a problem, because the only types it would deal in are Oid, bool, const char *, and List *. But you're right that in general this design pattern carries a risk of having to include the world in a commonly-used header file, which is certainly not a good idea. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 26 May 2010 14:57 On Wed, May 26, 2010 at 1:27 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > alvherre <alvherre(a)commandprompt.com> writes: >> Excerpts from Robert Haas's message of mié may 26 07:20:30 -0400 2010: >>> I still feel that we'd be better off putting all the functions that >>> use the same design pattern in a single file, rather than spreading >>> them out all over the backend. > >> This doesn't buy you anything, because that one header will likely have >> to #include all the other headers anyway. And if this is so, then all >> those headers will now be included in all files that require even a >> single one of these functions. > > For the particular case Robert is proposing, the *header* isn't a > problem, because the only types it would deal in are Oid, bool, > const char *, and List *. But you're right that in general this design > pattern carries a risk of having to include the world in a commonly-used > header file, which is certainly not a good idea. Right. I am very cognizant of the problem, but it isn't really an issue in this case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: alvherre on 26 May 2010 15:02 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(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 4 Prev: [HACKERS] mapping object names to role IDs Next: [PATCH] Move 'long long' check to c.h |