Assessment on namespace clean include file names
Here is what we install by default and what we could do about it:
c.h [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?
config.h rename to pg_config.h
ecpgerrno.h ok
ecpglib.h ok
ecpgtype.h ok
iodbc/ [3]- The names clash with the actual iodbc package. Not sure if this is intended, but I will evaluate with the odbc group.
iodbc.h
isql.h
isqlext.h
lib/ [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?
dllist.h
libpgeasy.h ok
libpgtcl.h ok
libpq/ [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-fs.h
pqcomm.h
libpq++/ ok
pgconnection.h
pgcursordb.h
pgdatabase.h
pglobject.h
pgtransdb.h
libpq++.h ok
libpq-fe.h ok
libpq-int.h [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?
os.h rename to pg_config_os.h
postgres_ext.h ok
postgres_fe.h [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?
pqexpbuffer.h [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?
sql3types.h [2]- The ecpg preprocessor will actually include copies of these into the output file when seeing the commands 'exec sql include sql3types;' etc., thus not really making these include files in the traditional sense. The names are okay for the moment, but I will research this some more.
sqlca.h [2]- The ecpg preprocessor will actually include copies of these into the output file when seeing the commands 'exec sql include sql3types;' etc., thus not really making these include files in the traditional sense. The names are okay for the moment, but I will research this some more.
[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?
name. Something should be done about that, such as not installing it, or
moving it to a "hidden" place. Ideas?
[2]: - The ecpg preprocessor will actually include copies of these into the output file when seeing the commands 'exec sql include sql3types;' etc., thus not really making these include files in the traditional sense. The names are okay for the moment, but I will research this some more.
the output file when seeing the commands 'exec sql include sql3types;'
etc., thus not really making these include files in the traditional sense.
The names are okay for the moment, but I will research this some more.
[3]: - The names clash with the actual iodbc package. Not sure if this is intended, but I will evaluate with the odbc group.
intended, but I will evaluate with the odbc group.
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
--prefix=/usr/local
libpq-fe.h => /usr/local/include/libpq-fe.h
access/xlog.h => /usr/local/include/postgresql/server/access/xlog.h
pg_config will get an option --server-includedir to point to the files.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
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
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
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).
"server" may not be a great choice if we want to stick libpq-int.h into
it too...
The directory wasn't meant as a place for hiding things to avoid using
them, it was supposed to be a really official place for interfacing to the
server. If we want to hide things maybe we should have an "obsolete"
subdirectory or some such.
"obsolete" is certainly not the right term either. Maybe we should have
an "interfaces" directory, parallel to "server", for internal-ish
includes of our interface libraries.
regards, tom lane
Import Notes
Reply to msg id not found: Pine.LNX.4.30.0108242129390.677-100000@peter.localdomainReference msg id not found: Pine.LNX.4.30.0108242129390.677-100000@peter.localdomain | Resolved by subject fallback
Tom Lane writes:
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).
"server" may not be a great choice if we want to stick libpq-int.h into
it too...
The directory wasn't meant as a place for hiding things to avoid using
them, it was supposed to be a really official place for interfacing to the
server. If we want to hide things maybe we should have an "obsolete"
subdirectory or some such.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter