public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniele Varrazzo <[email protected]>
To: Federico Di Gregorio <[email protected]>
Cc: [email protected]
Subject: Re: Feature branches merged to master for 2.8 release
Date: Mon, 29 Oct 2018 12:07:44 +0000
Message-ID: <CA+mi_8b9rM8+wo=f1Z3wTfH+D0J047mFYm=G5ZXJx8VOdXhoqg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CA+mi_8aVzn-4Ujuqg5aMduHjL1XQ3Y7sUU86s3p6shMefaPoSQ@mail.gmail.com>
<[email protected]>
<CA+mi_8bSZw7CAFPOKyanYVu2_AbP-+gcUd8N7oD-oisgth6o6A@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+mi_8bV4sq2HgAvMEx3ea6semu7g9pmwaW3gej4-peJHzO9Dg@mail.gmail.com>
<[email protected]>
On Mon, Oct 29, 2018 at 11:47 AM Federico Di Gregorio <[email protected]> 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
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Feature branches merged to master for 2.8 release
In-Reply-To: <CA+mi_8b9rM8+wo=f1Z3wTfH+D0J047mFYm=G5ZXJx8VOdXhoqg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox