Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9CJ7-0002iP-JX for psycopg@arkaria.postgresql.org; Sun, 07 Oct 2018 16:53:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g9CJ5-0002Hy-JU for psycopg@arkaria.postgresql.org; Sun, 07 Oct 2018 16:53:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9CJ5-0002Hr-D9 for psycopg@lists.postgresql.org; Sun, 07 Oct 2018 16:53:27 +0000 Received: from sonic306-20.consmr.mail.ir2.yahoo.com ([77.238.176.206]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g9CIx-0005lw-NE for psycopg@lists.postgresql.org; Sun, 07 Oct 2018 16:53:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1538931197; bh=2FQCH44VxunNNGCCRJqNzzz5+QYTKImeEQmdWPwTXbI=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=hpZWJuh6qDOai9To5Mew3AOTgmMAD+T/gZT5x8Y+MDrJyupmArtPzdkAnDF5/g3c5Ddwk7HdXf18M1JaaTGmZYraNFLlmhIIPQTxQ53R/RnsoTidXxzkCCYERWbuoBHrtaXOVjzQhavsJ1nRe7QR2VWxZqfvjINfwwO5opl/slgjnenmAhAAYKwJKHkaWzP46ksxSM+xCo0Hu0VAXlJMTlLYc1e4NoD0D+IkurGe84XlSJn+6m1eH5vaSnnw6hMMhKSbaJJwVF2wXyQX0Fn+BPjqQr91WUTINN/GGbLuuNU5/k93ocZgE/lr1KQYXd7clAR2PVnHIYrQmqGqIzddmg== X-YMail-OSG: 6kNJ4dwVM1lzQbiMBXI2b4m940Nv_bnz9t775TE4isv17UUXfaPXDnL02iSsGrh Z1eF3kaUT8zSyyYcSdqiFpJNVi80.y5MjM4rspigPQfAtX78k0R1ZYmUCG9mnJ1hJj2WgpZdw_K9 2rSFWV1lkiQYPx13B_4p4G32WJkRhbfIBPw6xwtCpbHE5JNqJdava3aB6JPxgLz6tySO4wKqY68M EkEXtOxFx0Tz3ToQKRzGGXcpoPt4A2y2uMufTRg.Iwe6kvoPyCPxwagH7VhA9Zr70BRYH9yeQlDU 20wLXR2p16kyU2LISIMMllroJcyv2.mpcjsr0YYR5dEi_QOrZXZkE73XoZC_gZaWJhS.rQg_FjrC Oct1KvcZJcPL2Gc_y_l0jPiMeVPa4V4osydwu5rchIjMi0PQIlebWZODH1ARFfjBkYTFES.Jav4Q QopChEQvOCo17f5on2R01eR_KufiLAEMWlqUvFlkGDbn95DfxoedQOCnSMJv_d5Qt0yox28JOxgS DB8kVmMI3zDLdTYg.j3JGOr_4ps79F3wEa_IlARxazBFeDRoR7sohgY6rdEgU6YClvaWSLr_UPkN G9zoAliooURHv18emAGoEaQQrTumcTL1boe7_WmbdY7S3GT661LVX4Sl1z4BV..RY6HnlbEePPJ6 PExOX5Og5_uVY0cvbD7GLnxQJebUo1HSk3kd_Zhg6ROH36xydc7t0mOw12xUVHZ6x74utwA2A.Sa 0rbx44WhcqKLUoPdgBwPVqhzDpZ3VmVJ3sTalDYOQWLvju4_OfJrJOdy4JPuwhjLWbtqC6KGvf15 FsNKCCsTQ43M4TdjCS6Wcewz7DIKd83Uy_QU_23nu_QRCtozY0YZm.CNnH6HjDc.Pt.hzQVitks0 fYPWEHsG4RKCx5F9kNBUts5C21gmf2ndH7kVGg4r4pDVUr.EHtpBrnsURR6UDr1ZzwSy1GyVmef0 hVpAUpkrJqX2r9DjpMflRZ218gppTzpqo7f3Kh2uwVdZov6D0PNrtdFIhEKRvYVp3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Sun, 7 Oct 2018 16:53:17 +0000 Date: Sun, 7 Oct 2018 16:53:15 +0000 (UTC) From: Christian Ferrari Reply-To: Christian Ferrari To: psycopg@lists.postgresql.org Message-ID: <153117058.7877280.1538931195126@mail.yahoo.com> In-Reply-To: <634068058.7859603.1538930530793@mail.yahoo.com> References: <1005537726.6324310.1538685211791@mail.yahoo.com> <602182297.6960405.1538755378178@mail.yahoo.com> <618fbba4-0f31-2e44-8517-a158cccbef0d@dndg.it> <634068058.7859603.1538930530793@mail.yahoo.com> Subject: Re: Integration of Psycopg with XTA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7877279_833393036.1538931195122" X-Mailer: WebService/1.1.12512 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Content-Length: 13124 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_7877279_833393036.1538931195122 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for disturbing with my previous email... :(It was my fault: I didn't = remember to check the key associated to the pointer in the capsule, now it'= s "psycopg2.connection.native_connection"... Everything works as expected, get_native_connection() can be even inlined l= ike below: xar1 =3D PostgresqlXaResource(rm1.get_native_connection(), "PostgreSQL", "d= bname=3Dtestdb") Thank you so much for your support.Kind RegardsCh.F. Il domenica 7 ottobre 2018, 18:42:31 CEST, Christian Ferrari ha scritto: =20 =20 Hi Federico,I've just tryed out commit https://github.com/fogzot/psycopg2/= commit/81addddaee2c690e925bb8f381e7bcb02ca97687 : get_native_connection() i= s in the interface, but unfortunately it seems to work differently than the= old _raw_pgconn. Here's my code snippet: pgconn =3D rm1.get_native_connection()#pgconn =3D rm1._raw_pgconn=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0 xar1 =3D PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=3Dtestdb") using get_native_connection(), I catch an error from XTA, the PGconn pointe= r is null. I have reversed back to commit https://github.com/fogzot/psycopg2/commit/cc= ae5cae34051d6640ec6cbce6d9313778c509d3 : _raw_pgconn works as before. Here's the code snippet: #pgconn =3D rm1.get_native_connection()=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 pgconn =3D rm1._raw_pgconn xar1 =3D PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=3Dtestdb") It works fine. Should "get_native_connection()" used differently than "_raw_pgconn" ? What= type of data are necessary to investigate the issue? Thanks in advanceKind RegardsCh.F. ------------------------------------------------------------- Good design can't stop bad implementation =20 Il domenica 7 ottobre 2018, 13:56:49 CEST, Federico Di Gregorio ha scritto: =20 =20 On 10/05/2018 06:02 PM, Christian Ferrari wrote: > In a previous mail I stated something like "the name of the method=20 > doesn't matter"... > ... after better thinking I realized a decent name might be better than= =20 > other ones... > Let me say: >=20 > get_native_conn() > get_native_connection() >=20 > might be better than "get_/something/_pgconn" because the same type of=20 > method could be useful for other databases in the future... > More or less all the databases use a "native connection", only=20 > PostgreSQL uses "PGconn connection". After some more checking I discovered that it isn't possible to=20 "invalidate" a PyCapsule so there is no way to tell if the pointer=20 inside it is still a valid libpq connection. The current code (feel free to pull) adds a new method get_native_connection() that raise an exception if called on a closed connection. I better like=20 a method here because it gives the idea that you need to call it every=20 time you want a Capsule to pass to the target C API. I also added some docs and a dumb test. https://github.com/fogzot/psycopg2/tree/feature-expose-pgconn @Daniele, if Christian reports no problems I'll merge this later for 2.8. federico --=20 Federico Di Gregorio=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 federico.digregorio@dndg.it DNDG srl=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dndg.it =C2=A0 Io non sono romantica. La candelina sul tavolo mi vede e si spegne. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- sisterconfusion =20 ------=_Part_7877279_833393036.1538931195122 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for dist= urbing with my previous email... :(
It was my fault: I didn't rem= ember to check the key associated to the pointer in the capsule, now it's "= psycopg2.connection.native_connection"...

Everything works as expected, get_native_connection() = can be even inlined like below:

xar1 =3D Pos= tgresqlXaResource(rm1.get_native_connection(), "PostgreSQL", "dbname=3Dtest= db")

Thank you so much for your support.
Kind = Regards
Ch.F.

=20
Il domenica 7 ottobre 2018, 18:42:31 CEST, Christian Fe= rrari <camauz@yahoo.com> ha scritto:


Hi Federico,
I've just tryed out commit= http= s://github.com/fogzot/psycopg2/commit/81addddaee2c690e925bb8f381e7bcb02ca97= 687 : get_native_connection() is in the interface, but unfortunately it= seems to work differently than the old _raw_pgconn.

Here's my code snippet:

pgconn =3D rm1.get_native_connection()
#pgconn =3D rm1._raw_pgconn      = ;            &n= bsp;            = ;            &n= bsp;           
xar1 =3D PostgresqlXaResource(pgconn, "PostgreSQL", "dbname=3Dtes= tdb")

using get_native_con= nection(), I catch an error from XTA, the PGconn pointer is null.

I have reversed back to commit https://github.com= /fogzot/psycopg2/commit/ccae5cae34051d6640ec6cbce6d9313778c509d3 : _raw= _pgconn works as before.

Here's the= code snippet:

#pgconn =3D rm= 1.get_native_connection()        &n= bsp;            = ;            &n= bsp;         
pgc= onn =3D rm1._raw_pgconn
xar1 =3D PostgresqlXaResource(pgc= onn, "PostgreSQL", "dbname=3Dtestdb")

=
It works fine.

Should "= get_native_connection()" used differently than "_raw_pgconn" ? What type of= data are necessary to investigate the issue?

=
Thanks in advance
Kind Regards
Ch.F.

-------------------------------= ------------------------------
Good design can't stop bad implementation


=20
=20
Il domenica 7 ottobre 2018, 13:56:49 CEST, Federico Di = Gregorio <fog@dndg.it> ha scritto:


On 10/05/2018 06:02 PM, Christian Fer= rari wrote:
> In a previous mail I stated something li= ke "the name of the method
> doesn't matter"...
> ... after better thinking I realized a decent name might = be better than
> other ones...
>= Let me say:
>
> get_native_conn= ()
> get_native_connection()
> > might be better than "get_/something/_pgconn" because= the same type of
> method could be useful for other = databases in the future...
> More or less all the data= bases use a "native connection", only
> PostgreSQL us= es "PGconn connection".

After some mor= e checking I discovered that it isn't possible to
"inval= idate" a PyCapsule so there is no way to tell if the pointer
inside it is still a valid libpq connection.

The current code (feel free to pull) adds a new method

get_native_connection()

that raise an exception if called on a closed connection. I = better like
a method here because it gives the idea that= you need to call it every
time you want a Capsule to pa= ss to the target C API.

I also added s= ome docs and a dumb test.

https://github.com/fogzot/psycopg2/tre= e/feature-expose-pgconn

@Daniele, = if Christian reports no problems I'll merge this later for 2.8.


feder= ico

--
Federico Di = Gregorio                  &nbs= p;     federico.digregorio@dndg.it
DNDG srl              &nb= sp;                     &= nbsp;             http://dndg.it
<= br clear=3D"none">  Io non sono romantica. La candelina sul tavolo mi = vede e si spegne.
          &nbs= p;                     &n= bsp;                     = -- sisterconfusion


------=_Part_7877279_833393036.1538931195122--