Re: mapping object names to role IDs

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

On Wed, May 26, 2010 at 1:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> alvherre <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message alvherre 2010-05-26 19:02:57 Re: mapping object names to role IDs
Previous Message Josh Berkus 2010-05-26 18:46:39 Re: Idea for getting rid of VACUUM FREEZE on cold pages