[PyGreSQL] [962] trunk/docs/contents: Some improvements to the docs by Justin Pryzby

2019-01-04 Thread NULL
Title: [962] trunk/docs/contents: Some improvements to the docs by Justin Pryzby Revision 962 Author cito Date 2019-01-04 17:32:04 -0500 (Fri, 04 Jan 2019) Log Message Some improvements to the docs by Justin Pryzby Modified Paths branches/5.0.x/docs/contents/pg/adaptation.rst

Re: [PyGreSQL] "TypeError: Connection is not valid" on exit from Python

2019-01-04 Thread Christoph Zwerschke
Am 03.01.2019 um 18:10 schrieb Jacob Champion: > Bump. Is anyone else able to reproduce this exit exception, and does > the proposed fix make sense? Thank you Jacob. I have created a GitHub issue here and will look into this later: https://github.com/Cito/PyGreSQL/issues/11 -- Christoph

[PyGreSQL] query formatting is nearly 10x slower than query

2019-01-04 Thread Justin Pryzby
Sigh. I initially sent this Jan 2 to "pyg...@telsasoft.com" ..and didn't notice the bounce back. I was going to do a performance test for prepared queries, specifically for INSERTs: simple queries , query_formatted , inline=True/False , SQL EXECUTE , pgdb , dicts ,and PQexecPrepared. I didn't

Re: [PyGreSQL] "TypeError: Connection is not valid" on exit from Python

2019-01-04 Thread Jacob Champion
On Thu, Sep 13, 2018 at 3:02 PM Jacob Champion wrote: > With the following reproduction script, which uses the classic API and > DB-API in tandem, > [...] > we get the following exception when the Python interpreter exits: Bump. Is anyone else able to reproduce this exit exception, and does

[PyGreSQL] [960] trunk: Update version numbers

2019-01-04 Thread NULL
Title: [960] trunk: Update version numbers Revision 960 Author cito Date 2019-01-04 12:49:21 -0500 (Fri, 04 Jan 2019) Log Message Update version numbers Modified Paths branches/5.0.x/docs/about.txt branches/5.0.x/docs/announce.rst branches/5.0.x/docs/conf.py

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Justin Pryzby
On Fri, Jan 04, 2019 at 10:03:17PM +0100, Christoph Zwerschke wrote: > Am 04.01.2019 um 21:44 schrieb Justin Pryzby:> On Fri, Jan 04, 2019 at > >Just curious, are you planning to include iterators in 5.1 or 5.2 ? I'm > >hoping to put prepared statements in place within the next month > >or so, and

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 21:44 schrieb Justin Pryzby:> On Fri, Jan 04, 2019 at 08:47:38PM +0100, Christoph Zwerschke wrote: >> Next wormhole will be the iterator support :) > Just curious, are you planning to include iterators in 5.1 or 5.2 ? I'm hoping to put prepared statements in place within the

Re: [PyGreSQL] proofread docs

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 22:00 schrieb Justin Pryzby: > I proofread the docs. PFA patch with suggested changes. Thanks, that's greately appreciated. Will push this into the repository. -- Christoph ___ PyGreSQL mailing list PyGreSQL@Vex.Net

[PyGreSQL] proofread docs

2019-01-04 Thread Justin Pryzby
I proofread the docs. PFA patch with suggested changes. -- Justin Pryzby System Administrator Telsasoft +1-952-707-8581 Index: docs/contents/general.rst === --- docs/contents/general.rst (revision 961) +++

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Justin Pryzby
On Fri, Jan 04, 2019 at 08:47:38PM +0100, Christoph Zwerschke wrote: > Next wormhole will be the iterator support :) Just curious, are you planning to include iterators in 5.1 or 5.2 ? I'm hoping to put prepared statements in place within the next month or so, and considered including a patched

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 20:08 schrieb Justin Pryzby: > On Fri, Jan 04, 2019 at 07:42:28PM +0100, Christoph Zwerschke wrote: >> Yes, I think this is the case. And I got the impression that even >> simple PQexecs annihilate existing unnamed statements. Did you also >> see that? > > I'll check more

[PyGreSQL] [961] trunk: Revert to name of prepared query as positional arg

2019-01-04 Thread NULL
Title: [961] trunk: Revert to name of prepared query as positional arg Revision 961 Author cito Date 2019-01-04 14:43:23 -0500 (Fri, 04 Jan 2019) Log Message Revert to name of prepared query as positional arg Unnamed prepared queries are not really useful due to their limited lifetime.

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Justin Pryzby
On Fri, Jan 04, 2019 at 07:42:28PM +0100, Christoph Zwerschke wrote: > Yes, I think this is the case. And I got the impression that even simple > PQexecs annihilate existing unnamed statements. Did you also see that? I'll check more shortly. Sorry for leading you down this wormhole.. Justin

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 19:10 schrieb Justin Pryzby: Currently it calls PQexecParams which (I think you agree) is creating unnamed prepared statements behind the scenes. Just found this in the docs (https://www.postgresql.org/docs/11/protocol-flow.html): "An unnamed prepared statement lasts only

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 19:10 schrieb Justin Pryzby: > But instead should pygres use NAMED prepared statements for its > internal queries, to avoid its unnamed queries conflicting with > users' unnamed prepared> statements ? I fear that would open a whole new can of worms for us. We would need our

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Justin Pryzby
On Fri, Jan 04, 2019 at 05:43:12PM +0100, Christoph Zwerschke wrote: > Am 03.01.2019 um 22:52 schrieb Justin Pryzby:> One thought ; should "name" > be an kwarg with default name='' ? > > It's now implemented that way. But I noticed an issue with unnamed queries. > It seems like Postgres replaces

[PyGreSQL] [959] Fix an issue with the parameter() method test

2019-01-04 Thread NULL
Title: [959] Fix an issue with the parameter() method test Revision 959 Author cito Date 2019-01-04 12:20:28 -0500 (Fri, 04 Jan 2019) Log Message Fix an issue with the parameter() method test Modified Paths branches/5.0.x/tests/test_classic_connection.py

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 03.01.2019 um 22:52 schrieb Justin Pryzby:> One thought ; should "name" be an kwarg with default name='' ? It's now implemented that way. But I noticed an issue with unnamed queries. It seems like Postgres replaces the unnamed query as soon as it's running any other query. That means any

[PyGreSQL] [958] trunk: Add important note regarding unnamed prepared statements

2019-01-04 Thread NULL
Title: [958] trunk: Add important note regarding unnamed prepared statements Revision 958 Author cito Date 2019-01-04 11:24:55 -0500 (Fri, 04 Jan 2019) Log Message Add important note regarding unnamed prepared statements Modified Paths trunk/docs/contents/pg/db_wrapper.rst

[PyGreSQL] [957] trunk: Add documentation for prepared statements

2019-01-04 Thread NULL
Title: [957] trunk: Add documentation for prepared statements Revision 957 Author cito Date 2019-01-04 08:28:58 -0500 (Fri, 04 Jan 2019) Log Message Add documentation for prepared statements Modified Paths trunk/docs/contents/pg/connection.rst trunk/docs/contents/pg/db_wrapper.rst

Re: [PyGreSQL] prepared statements

2019-01-04 Thread Christoph Zwerschke
Am 04.01.2019 um 03:07 schrieb Justin Pryzby: > On Fri, Jan 04, 2019 at 12:26:59AM +0100, Christoph Zwerschke wrote: >> The question is now - should we use this different signature only >> in the DB wrapper method or already in the underlying method? > > I don't have any opinion on this. Ok, so

[PyGreSQL] [956] trunk: Make name in query_prepared a keyword-only parameter

2019-01-04 Thread NULL
Title: [956] trunk: Make name in query_prepared a keyword-only parameter Revision 956 Author cito Date 2019-01-04 06:29:11 -0500 (Fri, 04 Jan 2019) Log Message Make name in query_prepared a keyword-only parameter Modified Paths trunk/pg.py trunk/tests/test_classic_dbwrapper.py Diff