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
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 |