On Thu, Jan 12, 2017 at 11:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
