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
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
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
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
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
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
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
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
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)
+++
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
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
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.
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo