Re: mapping object names to role IDs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: mapping object names to role IDs
Date: 2010-05-26 13:45:53
Message-ID: 11363.1274881553@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-26 13:50:02 Re: ExecutorCheckPerms() hook
Previous Message Stephen Frost 2010-05-26 13:42:02 Re: ExecutorCheckPerms() hook