On Mon, Oct 29, 2018 at 11:47 AM Federico Di Gregorio <fog@dndg.it> wrote:
> I agree with
> Daniele here but the fact that the *content* of the capsule, i.e., the
> PGconn* can change depending of the libpq version you're loading is
> pretty scary. I'd like to warn the client code (Python warnings to be
> suppressed? mm..) but just prepending an underscore to the method name
> doesn't mean much. If we add `get_native_connection()` then it becomes
> an official and supported psycopg extensions and doesn't make sense to
> mark it as private API.
The PGconn is an opaque structure: its correct usage is through the
libpq functions. See also the note in
<https://www.postgresql.org/docs/current/static/libpq-status.html>:
"libpq application programmers should be careful to maintain the
PGconn abstraction. Use the accessor functions described below to get
at the contents of PGconn. Reference to internal PGconn fields using
libpq-int.h is not recommended because they are subject to change in
the future." If the structure changes and someone gets bitten by it
it's not really related to how much private the method is.
-- Daniele
