mapping object names to role IDs
in [PgSql]
|
From: Robert Haas on 26 May 2010 07:20 On Wed, May 26, 2010 at 5:27 AM, Peter Eisentraut <peter_e(a)gmx.net> wrote: > On sön, 2010-05-23 at 00:50 -0400, Robert Haas wrote: >> Oid get_<object-type>_oid(List *qualname, bool missingok); >> -or- >> Oid get_<object-type>_oid(char *name, bool missingok); >> >> Thus get_database_oid and get_tablespace_oid would remain unchanged >> except for taking a second argument, get_roleid and get_roleid_checked >> would merge, and all of the others would change to match that style. > > If you are doing some refactoring work in that area, maybe you can also > take care of the issue I talked about there: > http://archives.postgresql.org/pgsql-hackers/2008-12/msg00725.php > > """ > Our code contains about 200 copies of the following code: > > tuple = SearchSysCache[Copy](FOOOID, ObjectIdGetDatum(fooid), 0, 0, 0); > if (!HeapTupleIsValid(tuple)) > elog(ERROR, "cache lookup failed for foo %u", fooid); > """ > > It looks like your proposal would reduce that number significantly. Well, not directly, because I was proposing to do something about wanting to turn an object identified by name into an OID, rather than wanting to look up an OID and find a syscache tuple. But the same approach could be applied to the problem you mention. 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. It's true that that one file will then depend on all the catalog stuff, but it actually can limit dependencies a little bit on the other end, because if someone wants to call a bunch of these functions from the same file, they only need to include the one header where they are all declared, rather than all the individual files that contain the individual functions. And more to the point, it's way easier from a maintenance standpoint: there is much less chance that someone will change one function without changing all the others if they are all in the same place. -- 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: Tom Lane on 26 May 2010 09:45 Robert Haas <robertmhaas(a)gmail.com> writes: > 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. It's true that that one file will then > depend on all the catalog stuff, but it actually can limit > dependencies a little bit on the other end, because if someone wants > to call a bunch of these functions from the same file, they only need > to include the one header where they are all declared, This is nonsense, because the call sites are going to be places that are actually *doing* something with that catalog, and so will need not only the catalog .h file but any other support functions associated with doing work on that catalog. Centralizing the lookups will do nothing whatsoever to reduce dependencies; it'll just create a central file dependent on everything in addition to every dependency we have now. The closest equivalent we have now is lsyscache.c, which is not exactly a sterling example of how to design a module: it's got no conceptual consistency whatsoever. I'm for standardizing the API of lookup functions, but not for relocating them. 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 10:34 On Wed, May 26, 2010 at 9:45 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > This is nonsense You can assert that, but I don't agree. We certainly have places (comment.c being the obvious example) where we need to look up a name and map it to an OID without doing anything else, and actually I believe there are useful ways to refactor the code that might lead to more of this. Anyway, I think the code maintenance argument ought to carry a lot more weight than whether one or two small files get rebuilt for dependencies slightly more often. lsyscache.c might have no conceptual consistency but it's extremely useful, 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.). -- 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 11:01 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. It's true that that one file will then > depend on all the catalog stuff, but it actually can limit > dependencies a little bit on the other end, because if someone wants > to call a bunch of these functions from the same file, they only need > to include the one header where they are all declared, rather than all > the individual files that contain the individual functions. 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. -- Á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
From: Robert Haas on 26 May 2010 11:05 On Wed, May 26, 2010 at 11:01 AM, alvherre <alvherre(a)commandprompt.com> wrote: > 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. It's true that that one file will then >> depend on all the catalog stuff, but it actually can limit >> dependencies a little bit on the other end, because if someone wants >> to call a bunch of these functions from the same file, they only need >> to include the one header where they are all declared, rather than all >> the individual files that contain the individual functions. > > 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. Well, at any rate, I'm giving up on the argument. -- 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] mapping object names to role IDs Next: [PATCH] Move 'long long' check to c.h |