Semi-undocumented functions in libpq
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header files. For clarity I think we
should clarify the situation, either explicity declare them for
external users, or stop exporting them. Now that we've bumped the major
version of libpq, now is the perfect time to decide.
The functions in question are:
Used by psql:
all the PQExpBuffer functions (./internal/pqexpbuffer.h)
pg_encoding_to_char (./server/mb/pg_wchar.h)
pqsignal (./server/libpq/pqsignal.h)
Used by initdb and createdb:
pg_char_to_encoding (./server/mb/pg_wchar.h)
Used by initdb:
pg_valid_server_encoding (./server/mb/pg_wchar.h)
Not used by anyone:
pg_utf_mblen (./server/mb/pg_wchar.h)
pgresStatus (a way to access info from PQresStatus but not declared publically anywhere)
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header files. For clarity I think we
should clarify the situation, either explicity declare them for
external users, or stop exporting them. Now that we've bumped the major
version of libpq, now is the perfect time to decide.
Already done no? (at least on the platforms where we know how to
restrict it)
regards, tom lane
On Thu, May 04, 2006 at 12:47:39PM -0400, Tom Lane wrote:
Martijn van Oosterhout <kleptog@svana.org> writes:
Comparing the lists of functions exported by libpq and those declared
by libpq-fe.h turns up a fair number of descrepancies. Most of these
functions are declared by internal header files. For clarity I think we
should clarify the situation, either explicity declare them for
external users, or stop exporting them. Now that we've bumped the major
version of libpq, now is the perfect time to decide.Already done no? (at least on the platforms where we know how to
restrict it)
These functions are all in the exports.txt. I was just wondering if we
wanted to cut that list down any more...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
On Thu, May 04, 2006 at 12:47:39PM -0400, Tom Lane wrote:
Already done no? (at least on the platforms where we know how to
restrict it)
These functions are all in the exports.txt. I was just wondering if we
wanted to cut that list down any more...
AFAIK, everything that is in exports.txt was put there for a reason.
I'm happy with the situation as it stands (other than wanting to enforce
the exports.txt restriction on more platforms ...)
Did we come to a decision about whether to implement symbol versioning
for libpq?
regards, tom lane
On Thu, May 04, 2006 at 03:21:56PM -0400, Tom Lane wrote:
AFAIK, everything that is in exports.txt was put there for a reason.
I'm happy with the situation as it stands (other than wanting to enforce
the exports.txt restriction on more platforms ...)
In that case, shouldn't we add to libpq-fe.h all the functions that
libpq is exporting?
Did we come to a decision about whether to implement symbol versioning
for libpq?
Not really. For distributors it's nice because it means that they don't
need to recompile the entire software stack just because a new postgres
release enters the archive. But for run-of-the-mill users who compile
postgres themselves, they won't notice one way or the other.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
On Thu, May 04, 2006 at 03:21:56PM -0400, Tom Lane wrote:
AFAIK, everything that is in exports.txt was put there for a reason.
I'm happy with the situation as it stands (other than wanting to enforce
the exports.txt restriction on more platforms ...)
In that case, shouldn't we add to libpq-fe.h all the functions that
libpq is exporting?
No, because we're only intending that stuff like psql and pg_dump use 'em.
regards, tom lane