Re: Assessment on namespace clean include file names

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Assessment on namespace clean include file names
Дата
Msg-id 29488.998609221@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Assessment on namespace clean include file names  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Assessment on namespace clean include file names  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: User locks code
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: User locks code