Re: [HACKERS] many copies of atooid() and oid_cmp() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] many copies of atooid() and oid_cmp()
Date
Msg-id CAB7nPqQX5qMs1ipqbGquABPSam-36YisqYXwsqL1A+E13rvhNg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] many copies of atooid() and oid_cmp()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 12, 2017 at 11:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 1/11/17 11:25 PM, Tom Lane wrote:
>>> +1 for the concept, but I'm a bit worried about putting atooid() in
>>> postgres_ext.h.  That's going to impose on the namespace of libpq-using
>>> applications, for instance.  A more conservative answer would be to
>>> add it to c.h.  OTOH, postgres_ext.h is where the Oid typedef lives,
>>> so I do see the consistency of adding this there.  Hard choice.
>
>> How about two copies: one in postgres_fe.h and one in postgres.h?
>
> That seems uglier than either of the other choices.
>
> I don't personally have a huge problem with adding atooid in
> postgres_ext.h, but I thought I'd better flag the potential issue
> to see if anyone else thinks it's a big problem.

FWIW, postgres_ext.h would make the most sense to me. Now, there is
one way to not impose that to frontends linked to libpq which would be
to locate it in some new header in src/include/common/, where both
backend and frontend could reference to it.
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Packages: Again
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] WIP: [[Parallel] Shared] Hash