Title: [969] trunk: Shebang should not be followed by a blank
Revision 969
Author cito
Date 2019-04-19 09:35:23 -0400 (Fri, 19 Apr 2019)
Log Message
Shebang should not be followed by a blank
It's a myth that it is needed because some old versions of Unix expect it.
However, some editors
Title: [970] trunk/pg.py: Avoid raising AttributeError
Revision 970
Author cito
Date 2019-04-19 09:39:56 -0400 (Fri, 19 Apr 2019)
Log Message
Avoid raising AttributeError
This might be slightly better in Python 3.
Also, handle the case when an AttributeError is raised
inside the pg_repr
Title: [971] Minor code simplification in format_query()
Revision 971
Author cito
Date 2019-04-19 14:27:41 -0400 (Fri, 19 Apr 2019)
Log Message
Minor code simplification in format_query()
Modified Paths
branches/5.0.x/pg.py
trunk/pg.py
Diff
Modified: branches/5.0.x/pg.py (970 =>
Title: [972] trunk/pg.py: Speed-up guessing simple types
Revision 972
Author cito
Date 2019-04-19 15:37:34 -0400 (Fri, 19 Apr 2019)
Log Message
Speed-up guessing simple types
Modified Paths
trunk/pg.py
Diff
Modified: trunk/pg.py (971 => 972)
--- trunk/pg.py 2019-04-19 18:27:41
Title: [973] trunk/docs/contents/pg: Add note about executing multiple SQL commands
Revision 973
Author cito
Date 2019-04-19 16:59:02 -0400 (Fri, 19 Apr 2019)
Log Message
Add note about executing multiple SQL commands
Also mention performance penalty of query_formatted().
Modified
Am 19.01.2019 um 18:24 schrieb Justin Pryzby:
1) in 5.0, document that relative to query, query_formatted has an overhead
"which can be significant for queries repeated many times", and document that
the mitigation is to use inline=True; or, use prepared statements "available
since 5.1". Note
Thanks for looking at this
On Fri, Apr 19, 2019 at 09:46:18PM -, PyGreSQL issue tracker wrote:
> But I think the huge performance difference in your example is only an
> artifact of the special kind of query you were using, with very simple
> values (just integer zeroes) and many columns.
