Re: mapping object names to role IDs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: mapping object names to role IDs
Date: 2010-05-26 11:20:30
Message-ID: AANLkTinNYnykYwoDlshexpCWTjLOOp_ci9plbSMGuZgB@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 26, 2010 at 5:27 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alastair Turner 2010-05-26 12:37:40 Re: Synchronization levels in SR
Previous Message Robert Haas 2010-05-26 11:10:45 Re: Synchronization levels in SR