On Wed, May 26, 2010 at 5:27 AM, Peter Eisentraut <pete...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
