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
|
Список | 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 по дате отправления: