Re: Assessment on namespace clean include file names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assessment on namespace clean include file names
Date: 2001-08-23 23:27:01
Message-ID: 29488.998609221@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> [1] -- The libpq-int.h draws in a lot of internal structure, true to the
> name. Something should be done about that, such as not installing it, or
> moving it to a "hidden" place. Ideas?

libpq-int.h was always intended to be strictly internal. I made it part
of the export fileset when it was created because I feared that there were
probably applications out there that were using direct access to fields of
PGresult, and I wanted to give them breathing room to update their code.
But at this point they've had several releases worth of breathing room.
I see no reason why we can't drop the other shoe and stop exporting
libpq-int.h (or more accurately, move it out of the public namespace,
same as you propose for backend headers).

> The idea I currently have for the installation layout including the server
> includes is this:

> --prefix=/usr/local/pgsql

> libpq-fe.h => /usr/local/pgsql/include/libpq-fe.h
> access/xlog.h => /usr/local/pgsql/include/server/access/xlog.h

"server" may not be a great choice if we want to stick libpq-int.h into
it too...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-08-23 23:34:40 Re: User locks code
Previous Message Mikheev, Vadim 2001-08-23 23:24:39 RE: User locks code