Re: many copies of atooid() and oid_cmp()

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: many copies of atooid() and oid_cmp()
Date: 2017-01-13 00:43:26
Message-ID: CAB7nPqQX5qMs1ipqbGquABPSam-36YisqYXwsqL1A+E13rvhNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 12, 2017 at 11:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-01-13 01:36:19 Re: WIP: [[Parallel] Shared] Hash
Previous Message Tom Lane 2017-01-13 00:00:07 pgsql: Fix field order in struct catcache.