Thread: 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/ > 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/ > 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/ > 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