I finally discovered what it is that "nose" does without arguments.
It's skipping executable files - running "nosetests --exe" runs all the tests.
Is it deliberate to skip the others by default ?
--
Justin
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
On Mon, Jan 31, 2022 at 12:08:30AM +0100, Christoph Zwerschke wrote:
> Hi all,
>
> I just published a 5.2.3 patch release.
Thanks for doing that.
I'm installing it everywhere in sight :)
--
Justin
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
On Sat, Jan 29, 2022 at 10:02:20PM +0100, c...@online.de wrote:
> On 29.01.2022 21:37, Justin Pryzby wrote:
> > Can I suggest this bug should be fixed and then make a release soon ?
>
> This is https://github.com/PyGreSQL/PyGreSQL/issues/65, right?
Yes
> Are there any oth
On Tue, Sep 14, 2021 at 11:04:17AM +0200, Christoph Zwerschke wrote:
> On 14.09.2021 03:03, Justin Pryzby wrote:
> > The solution is to use oid::regtype (rather than typname::regtype).
> >
> > self._query_pg_type = (
> > "S
In case you don't already know, the pygres website appears to be inaccessible.
--
Justin Pryzby
System Administrator
Telsasoft
+1-952-707-8581
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
On Fri, Sep 10, 2021 at 12:40:11PM +0200, Christoph Zwerschke wrote:
> On 10.09.2021 00:41, Justin Pryzby wrote:
> > python3 -c "import pg; db=pg.DB('postgres'); q=db.query('SELECT
> > array_agg(column_name) AS cols FROM
> > information_schema.columns').getresult(); pri
python3 -c "import pg; db=pg.DB('postgres'); q=db.query('SELECT
array_agg(column_name) AS cols FROM information_schema.columns').getresult();
print(q[0][0][0])"
{
python3 -c "import pg; db=pg.DB('postgres'); q=db.query('SELECT
array_agg(column_name::text) AS cols FROM
On Sun, Jun 27, 2021 at 10:14:49AM -0500, Justin Pryzby wrote:
> Maybe inserttable should be rewritten in python, to use all the adaptation
> logic and flexibility that already exists there. I started this, and seems to
> work fine. Obviously this break compatibility for any
Author: Justin Pryzby
Date: Sun Jun 27 09:14:35 2021 -0500
WIP: reimplement inserttable() as a DB() method
diff --git a/pg.py b/pg.py
index d9ee6e1..bdded31 100644
--- a/pg.py
+++ b/pg.py
@@ -1761,26 +1761,46 @@ class DB:
def inserttable(self, table, rows, columns=None
You'll see that I created another issue report.
As you might guess, I'm starting to look at using inserttable() here :)
Now, I have a question and possibly another issue with inserttable().
I called Adapt().adapt() to handle None/strings/bytes/list, and pass a list of
the adapted results to
It looks like inserttable() fails to call endcopy() when it raises exceptions
after calling "copy from":
else {
PyErr_SetString(
PyExc_TypeError,
"The second argument must contain a tuple or a list");
return NULL;
}
This
On Thu, May 06, 2021 at 10:35:20AM -0700, Evan Rempel wrote:
> repository:
> https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-7-x86_64/
That's built by Devrim et al (copied) and not by the pygres team.
> Previous builds of the PyGreSQL had an rpm requires list that included only
https://www.postgresql.org/docs/devel/libpq-pipeline-mode.html
strace -s999 -fe sendto,recvfrom python3.6 -c "import pg; db=pg.DB('host=/tmp
dbname=postgres'); db.set_non_blocking(True); db.enter_pipeline_mode();
q=db.send_query('SELECT generate_series(1,9)'); q2=db.send_query('SELECT
On Sun, Mar 28, 2021 at 04:25:23PM +0200, Christoph Zwerschke wrote:
> On 28.03.2021 16:11, Justin Pryzby wrote:
> > Here's some doc fixes. A couple of these I've had floating around in
> > an SVN> for a few years now... Feel free to sit on this patch and
> > I'll inclu
Here's some doc fixes. A couple of these I've had floating around in an SVN
for a few years now... Feel free to sit on this patch and I'll include it
again with my next patch series, whatever that is.
>From 2f68fe5d9b83b8ce695a465add55991c179cd6c7 Mon Sep 17 00:00:00 2001
From: Justin Pry
I was looking into supporting pg14 pipeline mode, which I think will rely on
the asynchronous processing mode new in pygres 5.2.
However this is crashing
gdb --args python3.6 -c "import pg; db=pg.DB('host=/tmp dbname=postgres',
nowait=True); print('nonblocking',db.is_non_blocking())"
Program
Note this new discussion which would make result format more flexible
https://www.postgresql.org/message-id/flat/40cbb35d-774f-23ed-3079-03f938aac...@2ndquadrant.com
On Fri, Dec 14, 2018 at 04:52:15PM +0100, Christoph Zwerschke wrote:
> Am 14.12.2018 um 15:11 schrieb Justin Pryzby:
> >
On Fri, Sep 25, 2020 at 08:57:35PM +0200, Christoph Zwerschke wrote:
> I just pushed out a 5.2.1 release that supports both PostgreSQL 13 (released
> today) and Python 3.9 (released next month).
Well done :)
I am furiously upgrading everything in sight.
--
Justin
Thanks for your work on pygres :)
BTW the postgres announce list might like to hear these, too.
--
Justin
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
On Sat, Jun 20, 2020 at 03:10:02PM +0200, Christoph Zwerschke wrote:
> Am 20.06.2020 um 04:02 schrieb Justin Pryzby:
> > I'm attaching my WIP patch. It will needs to be cleaned up, since (1) and
> > (2)
> > will surely cause rebase conflicts, so this is just a POC.
&
On Sat, Jun 20, 2020 at 01:10:14AM +0200, Christoph Zwerschke wrote:
> Am 20.06.2020 um 00:54 schrieb Justin Pryzby:
> > I think these would be easy to add.
> >
> > https://github.com/PyGreSQL/PyGreSQL/issues/29
> > The pgquery type should have a method listtyp
On Sat, Jun 20, 2020 at 12:43:23AM +0200, Christoph Zwerschke wrote:
> My plan is now to release version 5.2 tomorrow. Are there some things that I
> should still consider for the release? Then please let me know.
I think these would be easy to add.
https://github.com/PyGreSQL/PyGreSQL/issues/29
On Fri, Jun 19, 2020 at 11:42:22PM +0200, Christoph Zwerschke wrote:
> Am 19.06.2020 um 23:20 schrieb Justin Pryzby:
> >>> Also, I suggest to make sure the "statistics" here links to github:
> >>> https://pypi.org/project/PyGreSQL/
> >>
> >>
On Sun, Apr 19, 2020 at 11:14:43AM +0200, Christoph Zwerschke wrote:
> Am 19.04.2020 um 03:23 schrieb Justin Pryzby:
> > Also, I suggest to make sure the "statistics" here links to github:
> > https://pypi.org/project/PyGreSQL/
>
> Ok, I have reported the new URL
passing not types=[str('json')] but also
types=[pg.Json].
3) I suggested guess_simple_types() should handle Json() and Hstore()
4) I think we need an example of this, probably for types=list() and for
types=dict().
On Fri, Aug 23, 2019 at 11:01:11AM -0500, Justin Pryzby wrote:
> I underst
On Sat, Apr 18, 2020 at 04:20:34PM +0200, Christoph Zwerschke wrote:
> Am 18.04.2020 um 15:51 schrieb Justin Pryzby:
> > I guess it's a bugfix release. These is outstanding and small:
>
> Hi Justin, yes, quick bugfixes only. Larger changes will go to 5.2.
Also, I sugge
On Sat, Apr 18, 2020 at 08:38:21PM +0200, Christoph Zwerschke wrote:
> Am 18.04.2020 um 20:18 schrieb Justin Pryzby:
> > It works fine when I use import _pg, which is what I started doing at
> > telsasoft before raising this issue, and what I'll plan to continue.
> The expla
On Sat, Apr 18, 2020 at 05:57:44PM +0200, Christoph Zwerschke wrote:
> Am 18.04.2020 um 17:23 schrieb Justin Pryzby:
> > That didn't work.
> >
> > It did work to do this:
> > ProgrammingError = _pg.ProgrammingError
> >
> > Maybe __all__ can
On Sat, Apr 18, 2020 at 05:05:43PM +0200, Christoph Zwerschke wrote:
>
> Am 18.04.2020 um 16:19 schrieb Justin Pryzby:
> > I don't think we came to any conclusion about this, and I cannot find
> > it in github, and I cannot access trac...
> >
> > How should I use
On Sat, Apr 18, 2020 at 04:20:34PM +0200, Christoph Zwerschke wrote:
> Am 18.04.2020 um 15:51 schrieb Justin Pryzby:
> > I guess it's a bugfix release. These is outstanding and small:
>
> Hi Justin, yes, quick bugfixes only. Larger changes will go to 5.2.
>
> In 5.2 I a
pryzbyj@pryzbyj:/tmp$ pylint -E py
Using config file /home/pryzbyj/.pylintrc
* Module tmp.py
E: 3, 0: Module 'pg' has no 'ProgrammingError' member (no-member)
On Mon, Aug 19, 2019 at 11:07:17PM -0500, Justin Pryzby wrote:
> Also ... if it's what's easy, I'd be in favour of simply tell
a bugfix release. These is outstanding and small:
On Fri, Aug 23, 2019 at 11:13:21AM -0500, Justin Pryzby wrote:
> For me, on both py27 and py35 (which I don't otherwise use), it's ~50% faster
> to try:return dict[key]; except: pass than to test dict.get().
> At least for the common ca
On Sat, Mar 28, 2020 at 07:14:23PM +0100, Christoph Zwerschke wrote:
> Am 28.03.2020 um 18:56 schrieb Justin Pryzby:
> > Maybe that should be --with-ssl-info ? I found this:
>
> Not sure about that. In the context of setup.py and negative_opt, I only see
> the 'no-' pattern be
On Sat, Mar 28, 2020 at 06:24:12PM +0100, Christoph Zwerschke wrote:
> Am 28.03.2020 um 16:21 schrieb Justin Pryzby:
> > Also, you have every option defaulting to try, with the only consequence of
> > an
> > unsupported PG version being a warning. I mentioned that pa
On Sat, Mar 28, 2020 at 03:50:57PM +0100, Christoph Zwerschke wrote:
> Ok, I found that distutils even has a way to define "negative" options and
> used it in setup.py now:
>
> Please have a look at:
> https://github.com/PyGreSQL/PyGreSQL/commit/4b88231afd6bdfb40dca20780cdf006fe2346ea8
+
On Wed, Mar 25, 2020 at 12:25:12PM +0100, Christoph Zwerschke wrote:
> Am 25.03.2020 um 10:34 schrieb Justin Pryzby:
> > I think I would leave the "positive" variable names, and *add* negative
> > forms
> > of the commandline options. --no-foo and/or --fo
On Wed, Mar 25, 2020 at 10:08:25AM +0100, Christoph Zwerschke wrote:
>
> Am 25.03.2020 um 02:20 schrieb Justin Pryzby:
> > The old stuff can be removed eventually. I like this:
> >
> > if self.escaping_funcs and pg_version >= (9, 0):
> >
On Tue, Mar 24, 2020 at 09:10:18AM +0100, Christoph Zwerschke wrote:
> Maybe where we release binaries (currently only for Windows) we could ship
> them with a matching libql dll that will be installed with Pip alongside the
> PyGres dll?
I thinnk that would require the windows version of rpath
h when the function is eventually called, which is bad.
On Sat, Oct 05, 2019 at 11:04:35AM -0500, Justin Pryzby wrote:
> On Sat, Oct 05, 2019 at 04:48:40PM +0200, Christoph Zwerschke wrote:
> > >Find attached minimal patch.
>
> I thought it ought to have compile time check (for he
Dev ( 36) inserting JSON data
14441 F Aug 23 To pygresql@Vex ( 23) acceslerate get_simple_type
Update web docs to fix typos in changelog.
14197 F Jul 24 To pygresql@vex ( 155) largeobject docs
Create trac account for me?
14815 F Oct 05 To D'Arcy Cain ( 14) trac.pygresql.org
--
Justin P
On Thu, Oct 31, 2019 at 11:11:58AM -0500, Andrew M. Hettinger wrote:
> In light of this, how does one actually catch specific exceptions?
You can either acccess them from import pg (or import _pg).
I believe _pg will avoid warnings from pylint, but we were discussing how to
make that work for
I just played with this for the first time after seeing a question here:
https://www.postgresql.org/message-id/flat/VI1PR0701MB271869EC2BEDD69E1D0CEC86AE6D0%40VI1PR0701MB2718.eurprd07.prod.outlook.com
This is kind of neat, and allows returning arbitrarily large result sets to the
client library
On Sun, Oct 06, 2019 at 05:57:38PM +0200, Christoph Zwerschke wrote:
> Am 06.10.2019 um 15:20 schrieb Justin Pryzby:
> > Remember, lazy binding is the default on my machine, and my patch
> > doesn't DWIW here.. So I don't think adding lazy link options
> > is going to h
On Sun, Oct 06, 2019 at 01:03:21PM +0200, Christoph Zwerschke wrote:
> Am 06.10.2019 um 01:15 schrieb Justin Pryzby:
> >On Sat, Oct 05, 2019 at 11:43:23PM +0200, Christoph Zwerschke wrote:
> >..but I don't think it's a solution for pygres ? I tried it and still get a
> >sy
On Sat, Oct 05, 2019 at 11:43:23PM +0200, Christoph Zwerschke wrote:
> Am 05.10.2019 um 23:10 schrieb Christoph Zwerschke:
> >Just tried what you did with that t.c program, but strangely I get the
> >"undefined symbol" error when I downgrade libpq and run "./t 0", even when
> >LD_BIND_NOW is not
On Sat, Oct 05, 2019 at 07:47:50PM +0200, Christoph Zwerschke wrote:
>
> Am 05.10.2019 um 18:47 schrieb Justin Pryzby:
> > On Sat, Oct 05, 2019 at 06:37:36PM +0200, Christoph Zwerschke wrote:
> >> Are you sure you compiled that with the pgconfig.h of Postgres 12?
&
On Sat, Oct 05, 2019 at 04:48:40PM +0200, Christoph Zwerschke wrote:
> >Find attached minimal patch.
>
> Thank you, looks fine. I've already added docs and tests as well, but not
> yet committed to trunk.
I didn't mean you had to stop and do that - I hammered it out while waiting for
On Wed, May 15, 2019 at 08:44:49AM -0500, Justin Pryzby wrote:
> Also, as of PG12 (unreleased), there'll be this new interface:
> https://www.postgresql.org/docs/devel/release-12.html#id-1.3.7
> |Add libpq function to report the memory size of the query result (Lars
> Kan
On Fri, Sep 27, 2019 at 06:28:49PM +0200, Christoph Zwerschke wrote:
> Am 24.09.2019 um 01:57 schrieb Shoaib Lari:
> >I think it is definitely preferable that PyGreSQL should add schema
> >qualifications to all operators and system tables.
> >Please let me know if there are any plans for doing
On Sat, Aug 24, 2019 at 10:05:46PM +0200, Christoph Zwerschke wrote:
> Am 16.08.2019 um 19:58 schrieb Shoaib Lari:
> > I was wondering if the PyGreSQL community has any plans to address
> > PostgreSQL security vulnerability
> >
For me, on both py27 and py35 (which I don't otherwise use), it's ~50% faster
to try:return dict[key]; except: pass than to test dict.get().
At least for the common case of "key in dict".
d=dict(a=1)
for i in range(1,99):
#x = d.get('a')
#if x is not None: print (d['a'])
I understand that INSERT and SELECT value (without ::type) might need to be
specially casted, otherwise they end up as text.
I'd never needed to do this before and was surprised to see that I needed to
pass a types=['json'], or call json.dumps() to make it work at all.
Specifically, I thought it
Also ... if it's what's easy, I'd be in favour of simply telling people to
"import _pg" for the LO constants and exceptions.
On Tue, Aug 13, 2019 at 10:19:22AM -0500, Justin Pryzby wrote:
> Sorry, this was lost in my spam for three weeks..
>
> On Fri, Jul 26, 2019 at 10:42:14
Sorry, this was lost in my spam for three weeks..
On Fri, Jul 26, 2019 at 10:42:14AM +0200, Christoph Zwerschke wrote:
> Am 26.07.2019 um 05:20 schrieb Justin Pryzby:
>
> > Is there any way to avoid output like this?
> >
> > * Module telsasoft.
Is there any way to avoid output like this?
* Module telsasoft.db
E: 15, 0: No name 'ProgrammingError' in module 'pg' (no-name-in-module)
E: 24, 7: Module 'pg' has no 'version' member (no-member)
E: 28, 0: Module 'pg' has no 'set_bool' member (no-member)
E: 29, 0: Module 'pg' has no
, 2019 at 01:13:16PM -0500, Justin Pryzby wrote:
>
> Index: docs/contents/pg/large_objects.rst
> ===
> --- docs/contents/pg/large_objects.rst(revision 1017)
> +++ docs/contents/pg/large_objects.rst
Index: docs/contents/pg/large_objects.rst
===
--- docs/contents/pg/large_objects.rst (revision 1017)
+++ docs/contents/pg/large_objects.rst (working copy)
@@ -5,23 +5,24 @@
.. class:: LargeObject
-Objects that are instances of
I experienced errors while rearranging a portion of our project involving
largeobjects. This took an embarassingly long time for what boils down to 9
lines. In our project, I can work around it by writing a=b().c() rather than
a1=b(), a2=a1.c() (but there's only one class involved in this
On Fri, Jul 19, 2019 at 07:44:21PM -0500, Justin Pryzby wrote:
> On Fri, Jun 07, 2019 at 09:06:26PM +0200, Christoph Zwerschke wrote:
> > >pgdb has
> > >|Cursor.coltypes
> > >|The list of columns types of the current result set
> > >|The values in this li
On Fri, Jun 07, 2019 at 09:06:26PM +0200, Christoph Zwerschke wrote:
> >pgdb has
> >|Cursor.coltypes
> >|The list of columns types of the current result set
> >|The values in this list are the same values as the type_code elements in
> >the Cursor.description attribute. Always use the latter
I recommend to update web docs.
On Wed, Jun 19, 2019 at 03:14:30PM -0500, Justin Pryzby wrote:
> On Sat, Jun 15, 2019 at 10:25:04PM -0500, Justin Pryzby wrote:
> > On Sat, Jun 15, 2019 at 08:58:37PM +0200, Christoph Zwerschke wrote:
> > > Am 15.06.2019 um 03:08 sch
On Wed, Jun 19, 2019 at 03:14:30PM -0500, Justin Pryzby wrote:
> On Sat, Jun 15, 2019 at 10:25:04PM -0500, Justin Pryzby wrote:
> > On Sat, Jun 15, 2019 at 08:58:37PM +0200, Christoph Zwerschke wrote:
> > > Am 15.06.2019 um 03:08 schrieb Justin Pryzby:
> > > >Thanks
On Sat, Jun 15, 2019 at 10:25:04PM -0500, Justin Pryzby wrote:
> On Sat, Jun 15, 2019 at 08:58:37PM +0200, Christoph Zwerschke wrote:
> > Am 15.06.2019 um 03:08 schrieb Justin Pryzby:
> > >Thanks. What does it take to update the web docs ?
> >
> > https://pygresql
On Sat, Jun 15, 2019 at 08:58:37PM +0200, Christoph Zwerschke wrote:
> Am 15.06.2019 um 03:08 schrieb Justin Pryzby:
> >Thanks. What does it take to update the web docs ?
>
> https://pygresql.readthedocs.io/
> -> I need to push the current trunk to GitHub (done)
>
&
On Fri, Jun 07, 2019 at 07:50:18PM +0200, Christoph Zwerschke wrote:
> Am 07.06.2019 um 19:03 schrieb Justin Pryzby:
> > Here's another:
> > namedresult/namediter – get query values a named tuples
> >
> > should be AS named tuples ?
>
> This is all fixed in
On Wed, May 15, 2019 at 08:44:49AM -0500, Justin Pryzby wrote:
> Also, as of PG12 (unreleased), there'll be this new interface:
> https://www.postgresql.org/docs/devel/release-12.html#id-1.3.7
> |Add libpq function to report the memory size of the query result (Lars
> Kan
Here's another:
namedresult/namediter – get query values a named tuples
should be AS named tuples ?
On Fri, Jun 07, 2019 at 11:30:52AM -0500, Justin Pryzby wrote:
> Index: docs/contents/changelog.rst
> ===
> --- docs
Index: docs/contents/changelog.rst
===
--- docs/contents/changelog.rst (revision 1014)
+++ docs/contents/changelog.rst (working copy)
@@ -25,7 +25,7 @@
an error if the result does not have exactly one row.
- New methods
On Wed, May 22, 2019 at 11:01:12PM +0200, Christoph Zwerschke wrote:
>
> Am 22.05.2019 um 21:00 schrieb Justin Pryzby:
> > It looks like this doesn't work correctly.
> > query_prepared sends it sargumens to postgres without adaptation.
>
> Only the query_formatted() meth
It looks like this doesn't work correctly. query_prepared sends its arguments
to postgres without adaptation. For example pygres lists are sent to postgres
as [1,2] rather than {1,2} to be handled as arrays, and dict(a=1) is sent as
{'a': 1} rather than {"a": 1} for json.
I'm not sure what the
On Sun, May 19, 2019 at 04:49:04PM +0200, Christoph Zwerschke wrote:
> There is also another check in mktar that verifies the number of top level
> files. This has increased in trunk because pgmodule.c has been split into
> several files. But you changed that number already.
>
> Maybe in addition
On Sun, May 19, 2019 at 06:39:49PM +0200, Christoph Zwerschke wrote:
> Maybe this will do? Should work on both BSD and Linux.
>
> -- Christoph
>
>
> # Set proper file permissions
> find . -type d -exec chmod 755 {} \;
> find . -type f -exec chmod 644 {} \;
> chmod 755 docs/Makefile
On Fri, Apr 26, 2019 at 01:38:38AM +0200, Christoph Zwerschke wrote:
> PyGreSQL 5.1 (and 5.0.7) is ready for release now from my side. All tests
> are green for me on Linux and Windows with the supported Python and Postgres
> versions. Let me know if something does not work for you or I have
On Mon, Apr 22, 2019 at 10:44:59AM -0400, n...@vex.net wrote:
> Revision 980 Author cito Date 2019-04-22 10:44:58 -0400 (Mon, 22 Apr 2019)
+.. method:: Query.single()
+
+Get single row from the result of a query as a tuple
+
+:returns: single row from the query results as a tuple of
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.
-- There are two columns here:
>>> pg.DB('ts').query('SELECT x.b, y.a AS b FROM (SELECT 1 AS b )x JOIN (SELECT
>>> 1 AS a)y ON true').getresult()
[(1, 1)]
-- But here they're silently "collapsed" into one key:
>>> pg.DB('ts').query('SELECT x.b, y.a AS b FROM (SELECT 1 AS b )x JOIN (SELECT
>>> 2
I propose addressing this with a few related changes:
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".
I've never had a use for this, and didn't really know what it does.
I see ticket#44 http://trac.pygresql.org:8000/pgtracker/ticket/44
It talks about returning text instead of postgres type name.
And I see in pg.py and tests/:
_types = {'bool': 'bool',
'bytea': 'bytea',
On Sat, Jan 05, 2019 at 10:13:41PM +0100, Christoph Zwerschke wrote:
> Am 05.01.2019 um 17:42 schrieb Justin Pryzby:
> >On Fri, Jan 04, 2019 at 11:44:47PM +0100, Christoph Zwerschke wrote:
> >There's a few remaining chunks which I think are improvements. Please review
> &g
On Fri, Jan 04, 2019 at 11:44:47PM +0100, Christoph Zwerschke wrote:
> I kept the term "C extension" for the shared library since it has a
> well-known meaning in the Python world, but made it clearer that it's
> low-level (I guess that was your reasoning to not use the term).
Right, my thinking
On Fri, Jan 04, 2019 at 10:03:17PM +0100, Christoph Zwerschke wrote:
> In the spirit of RERO I think we should get 5.1 out soon (in 1-2 weeks) and
This appears to be a typo in r961
docs/contents/pg/db_wrapper.rst
-db.prepare("update employees set phone=$2 where ein=$1",
-
This is already settled but wanted to follow through on one point..
On Fri, Jan 04, 2019 at 07:42:28PM +0100, Christoph Zwerschke wrote:
> > Currently it calls PQexecParams which (I think you agree) is creating
> > unnamed prepared statements behind the scenes.
>
> Yes, I think this is the case.
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 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 n
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)
+++ docs/contents
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
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
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
On Fri, Jan 04, 2019 at 12:26:59AM +0100, Christoph Zwerschke wrote:
> Am 04.01.2019 um 00:08 schrieb Justin Pryzby:
> > I suggest it should actually be:
> >
> > |+def query_prepared(self, *args, **kwargs):
> > |+def prepare(self, command, **kwargs):
&g
On Thu, Jan 03, 2019 at 11:40:52PM +0100, Christoph Zwerschke wrote:
> Am 03.01.2019 um 23:12 schrieb Justin Pryzby:
> > I agree at least that there should be SOME method accepting $1
> > for prepared query, and that it's more important than a method
> > for using %s.
> &
On Fri, Jan 04, 2019 at 12:03:13AM +0100, Christoph Zwerschke wrote:
> 1. The order of params is now different from the underlying C function where
> the name comes first which could be confusing.
Doesn't matter at all except maybe to pygres developers, right ?
Or postgres developers who happen
On Thu, Jan 03, 2019 at 11:40:52PM +0100, Christoph Zwerschke wrote:
> Am 03.01.2019 um 23:12 schrieb Justin Pryzby:
> > I agree at least that there should be SOME method accepting $1
> > for prepared query, and that it's more important than a method
> > for using %s.
> &
On Thu, Jan 03, 2019 at 10:58:33PM +0100, Christoph Zwerschke wrote:
> Am 03.01.2019 um 22:52 schrieb Justin Pryzby:
> > On Thu, Jan 03, 2019 at 09:49:24PM +0100, Christoph Zwerschke wrote:
> > |+def query_prepared(self, name, *args):
> > |+def prepare(self, name,
On Thu, Jan 03, 2019 at 10:10:19PM +0100, Christoph Zwerschke wrote:
> Am 03.01.2019 um 21:58 schrieb Justin Pryzby:
> > On Thu, Jan 03, 2019 at 09:49:24PM +0100, Christoph Zwerschke wrote:
> >> db.prepare('insert-tweet', "INSERT INTO tweets VALUES($1, $2, $3)")
> &
On Thu, Jan 03, 2019 at 09:49:24PM +0100, Christoph Zwerschke wrote:
> Let me know what you think.
>
> I will also add documentation, but want to wait for feedback first. Maybe we
> want to change or add something.
|+def query_prepared(self, name, *args):
|+def prepare(self, name,
On Thu, Jan 03, 2019 at 10:10:19PM +0100, Christoph Zwerschke wrote:
> Am 03.01.2019 um 21:58 schrieb Justin Pryzby:
> > On Thu, Jan 03, 2019 at 09:49:24PM +0100, Christoph Zwerschke wrote:
> >> db.prepare('insert-tweet', "INSERT INTO tweets VALUES($1, $2, $3)")
> &
On Thu, Jan 03, 2019 at 09:49:24PM +0100, Christoph Zwerschke wrote:
> db.prepare('insert-tweet', "INSERT INTO tweets VALUES($1, $2, $3)")
My first thought is to ask why not use %s parameters ?
I'll look more at this later.
Thanks,
Justin
___
PyGreSQL
On Fri, Dec 21, 2018 at 05:58:43PM -0600, Justin Pryzby wrote:
> On Fri, Dec 14, 2018 at 11:11:03AM -0600, Justin Pryzby wrote:
> > I hacked query_formatted to accept an prepare=False.
> > The difficulty is in replacing %s with $1, which needs to either have a
> > list o
types that are not
supported by the C modul. Fore example,"
=> MODULE
=> FOR example,
http://www.pygresql.org/contents/pgdb/cursor.html#executemany-execute-many-similar-database-operations
Parameters are bounded
=> bound
This isn't just a typo, isn't this wrong??
days += 365 * years + 30
On Fri, Dec 14, 2018 at 11:11:03AM -0600, Justin Pryzby wrote:
> Find attached patch with proof of concept for minimal implementation of
> prepared statements.
> And for PQexecPrepared, I added a conditional in query(), since that entire
> function appears to be exactly w
1 - 100 of 141 matches
Mail list logo
