Hi all,
PyGreSQL 6.0 has been released now.
This version 6.0 does not include new features, but improves developer
experience with a modernized and more clearly arranged code base that
also provides type hints.
The supported versions are Python 3.7 - 3.12 and PostgreSQL 10 - 16.
For
Hi all,
PyGreSQL 6.0b1 is now available for testing.
As discussed, version 6.0 does not include new features, but improves
developer experience with a modernized and more clearly arrange code
base that also provides type hints.
The supported versions are Python 3.7-3.12 and PostgreSQL
Hi all,
the lastest release 5.2.5 of PyGreSQL now supports Python from 2.7 to
3.11 and PostgreSQL from 9.0 to 15.
It has become a burden to test and created builds for this wide range of
versions, some of which are not officially supported any more. I feel
the time has come to de-support
Hi all,
PyGreSQL 5.2.5 with some bugfixes and support for Python 3.11 and
Postgres 15 version has been released.
@D'Arcy: We currently have a problem with www.pygresql.org:
- the http link shows an old version
- the https link does not work (wrong domain name in certificate)
The best
On 24.06.2022 04:06, Justin Pryzby wrote:
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 ?
Not sure. Anyway, nose is totally outdated. Use pytest
Hi all,
I just published a 5.2.3 patch release.
Sources and binaries are available on PyPI and GitHub as always.
PyPI: https://pypi.org/project/PyGreSQL/
GitHub: https://github.com/PyGreSQL/PyGreSQL
The ChangeLog is here:
https://pygresql.readthedocs.io/en/latest/contents/changelog.html
If
On 14.09.2021 03:03, Justin Pryzby wrote:
> The solution is to use oid::regtype (rather than typname::regtype).
>
> self._query_pg_type = (
> "SELECT oid, typname, oid::regtype,"
>
> The docs show that's available since v9.3
>
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();
print(q[0][0][0])"
I think it should treat this as array[text] rather than text.
But I'm certain that it
Thanks for creating the issues.
Was not able to work on PyGres this weekend but it's on my to do list.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
Hi Justin,
thanks for the heads up - can you create separate GitHub issues for
these things and everything else that should go into the patch release?
I just added another issue today. Will try to create a bugfix release
covering these things over the weekend then.
Yes, the
On 28.03.2021 16:54, Justin Pryzby wrote:
As far as I see, these are already incorporated in the Git repo.
I don't think so
https://github.com/PyGreSQL/PyGreSQL/blob/master/docs/contents/pg/connection.rst
Ah, ok, I had already applied your patch when I looked :)
Pushed to the repo now.
--
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 include it again with my next patch series, whatever that is.
As far as I see, these are already
On 27.03.2021 22:45, Justin Pryzby wrote:
It looks like the PyArg_ParseTuple() can/should just be removed from the NOARGS
case, including poll().
That's true. I have fixed this in the master branch now.
The async support still needs some unit testing, and it seems some
important methods are
Hi all,
I just published a 5.2.2 bugfix release.
Sources and binaries are available on PyPI and GitHub as always.
Homepage: https://pygresql.org/
PyPI: https://pypi.org/project/PyGreSQL/
GitHub: https://github.com/PyGreSQL/PyGreSQL
The ChangeLog is here:
Hi all,
I just pushed out a 5.2.1 release that supports both PostgreSQL 13
(released today) and Python 3.9 (released next month).
Sources and binaries are available on PyPI and GitHub as always.
Homepage: https://pygresql.org/
PyPI: https://pypi.org/project/PyGreSQL/
GitHub:
PyGreSQL 5.2 has been released today
Download from PyPI:
https://pypi.org/project/PyGreSQL/5.2/#files
More downloads in other formats:
https://github.com/PyGreSQL/PyGreSQL/releases/tag/5.2
Changes:
https://pygresql.org/contents/changelog.html
Thanks to all who sent in contributions and
Am 20.06.2020 um 15:58 schrieb Justin Pryzby:
I think you could have just as well said the opposite (passing the
column names in the unesaped table names was a bad idea), since I was
on the verge of suggesting we just do document that :)
Right, you can argue that the feature existed all the
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.
Thank you. I have commited this after making a few amendments:
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 listtypes() #29
I sent a patch for this to the list last year
https://github.com/PyGreSQL/PyGreSQL/issues/24
Allow
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.
As a new feature, I have included support for asynchronous processing,
which was suggested on this mailing list quite a while ago. The feature
is still
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/
>>
>> Ok, I have reported the new URL now. May take a while to update.
>
> Looks like this didn't work ?
You mean the repository link is
I plan to work on PyGreSQL this week and will probably also cut a new
release then. If there are any other fixes you want to get into the
release, please open issues on GitHub.
-- Christoph
Am 15.06.2020 um 19:51 schrieb Tyler Ramer:
Hi,
We recently submitted a patch,
Ok, I think I was able to solve this by removing the "www" from the
cname file and the setting in the repository. Now "pygresql.org" is
shown properly via https, and www.pygresql.org redirects to it.
-- Christoph
___
PyGreSQL mailing list
Am 09.06.2020 um 15:03 schrieb D'Arcy Cain:
My FF on FreeBSD doesn't do that. Doesn't do it on Linux either.
Must be a Windows thing. Another reason not to run Windows as if I
needed more.
Don't think FF would behave differently on Windows in such matters. I
think the issue is that it
Am 09.06.2020 um 13:25 schrieb D'Arcy Cain:
> On 2020-06-09 07:19, Christoph Zwerschke wrote:
>> Looks like the certificate for www.pygresql.org has expired.
>> D'Arcy, since you own the domain, can you renew it?>
> I don't think that we ever had a certificate for PyGreSQL
Looks like the certificate for www.pygresql.org has expired.
D'Arcy, since you own the domain, can you renew it?
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
SQLAlchemy is currently deprecating many of the built-in dialects, one
of them for PyGreSQL, and are asking us to provide it as external
dialect in the future.
I will create a separate repository for that under
https://github.com/PyGreSQL - if anybody is interested in helping with
this let
The PyGreSQL 5.1.2 bugfix release is available for download now.
I have created a new maintenance branch 5.1.x, the master branch will be
used for 5.2 now.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
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 now. May take a while to update.
-- Christoph
___
PyGreSQL mailing
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 explanation is probably the same, because pylint doesn't analyze C
extensions by default, so it ignores
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 *limits* what's visible but not extend it. ?
It actually only defines what will be imported when you do a wildcard
import, and I
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 also want to desupport older Python versions like 2.6, 3.3 and
3.4. And start supporting static linking,
I plan to publish version 5.1.2 tomorrow, which fixes build problems
with MacOS and improves the handling of build options. If there are any
other small fixes that need to be included, let me know.
-- Christoph
___
PyGreSQL mailing list
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 being followed. Also, this is backward compatible.
-- Christoph
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 packages (at least in
the past for Debian) were encouraged to compile with --enable-foo --enable-bar..
..such
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
Let me know what you think about this change.
-- Christoph
Am 25.03.2020 um 12:28 schrieb Justin Pryzby:
I think (1) is more common, I think that's what autoconf and gnu
tools use.
In that case, maybe we should use enable/disable or with/without as
prefixes, like autotools? But I think it's not very common as setup
option. Also, by using the old
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 --foo=no
Yes, that would be nice. Unfortunately, the options are not interpreted
by us, but by distutils. The way the
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):
> define_macros.append(('ESCAPING_FUNCS', None))
> That allows a packager to disable a feature
> if they want the
Am 24.03.2020 um 05:46 schrieb Justin Pryzby:
This patch got stuck due to our limited understand of python's
dynamic loading of shared libraries. I picked it up again ince I
have some downtime..
Thanks for working on this problem. Would be great if we could resolve
it. Otherwise it always
Am 12.11.2019 um 14:09 schrieb D'Arcy Cain:
> Is the code ready now for a release? Does anyone know of anything
> missing that should be in it?
That code is ready to be released as 5.1.1.
We had one big open question that still needs to be resolved: How to
deal with new/optional
Am 06.10.2019 um 21:39 schrieb Justin Pryzby:
> That doesn't explain it :(
>
> Find attached t.c building t.so...
Thanks. At least we have ruled that out :/
Winter is coming and maybe we can find some rainy weekend to investigate
deeper and learn a thing or two about the sacred science of
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 help. I think because of something python is doing (??)
Another difference is that in your example
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
symbol resolution error. So, unless someone knows or finds better, it means
there's nothing stopping
Am 05.10.2019 um 23:33 schrieb Justin Pryzby:
> You probably realized that my email failed to show that I
> downgraded libpq between invocacations of "PGDATABASE=postgres ./t 1"
Yes, I understood what you were doing. But I could only reproduce it
when adding the "-Wl,-z,lazy" option. Not sure
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 defined. I am using Ubuntu instead of Debian,
but that sh
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?
>> setup.py is using the includes specified by the pgconfig tool.
> The intended
Am 05.10.2019 um 18:04 schrieb Justin Pryzby:
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
Am 05.10.2019 um 02:07 schrieb Justin Pryzby:
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
Am 03.10.2019 um 14:25 schrieb D'Arcy Cain:
> On 2019-10-03 8:14 a.m., Christoph Zwerschke wrote:
> I suspect that a month should be plenty of time to test everything so
> I am looking at a mid-November release. Does that work for everyone?
I don't think we need to wait unt
Am 02.10.2019 um 22:53 schrieb Jacob Champion:
On Wed, Oct 2, 2019 at 12:52 PM Justin Pryzby wrote:
It looks good to me.
Looks correct to my eye as well.
Thanks for the feedback. I have now also added a regression test that
can also serve as a demonstration of the problem.
Before
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 so.
I have now implemented this in r1019.
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 so.
Thanks Shoaib and Jacob for the reminder. Since there was no negative
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
>
https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path.
Hi Shoaib, thanks for bringing this to our attention.
>
Am 26.07.2019 um 05:20 schrieb Justin Pryzby:
> 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)
> ...
>
> I assume it's related to this:
>
> |def __getattr__(self, name):
> |
Thanks for reporting. Created a ticket and will try look into this over
the weekend.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
Am 20.07.2019 um 02:44 schrieb Justin Pryzby:
>> You would get the types via attnames().
> I'm not sure if I understood the last sentence.
> Do you mean the types of column in a table ?
> That's not the same as types of result columns, though.
Sure, I just wanted to explain why Pygres did not
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)
http://www.pygresql.org/
-> D'Arcy needs to run the mkdocs script on the server
-- Christoph
Am 09.06.2019 um 00:38 schrieb Justin Pryzby:
> I see this interface has been around since PyGreSQL 3.1 (c. 2000),
> but "source objects" are not documented.
>
> I'm referring to these:
> |pg.DB('postgres').source()
> |pg.connect('postgres').source()
This is deliberate. It's an internal object
Am 07.06.2019 um 20:03 schrieb Justin Pryzby:
|Add libpq function to report the memory size of the query result (Lars Kanis,
Tom Lane)
|The function is PQresultMemorySize().
We already have a ticket for this:
http://trac.vex.net:8000/pgtracker/ticket/80
pgdb has
|Cursor.coltypes
|The
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 the trunk now, thank you.
-- Christoph
___
PyGreSQL mailing list
Am 04.06.2019 um 03:09 schrieb Justin Pryzby:
> On Wed, May 22, 2019 at 11:01:12PM +0200, Christoph Zwerschke wrote:
>> Not sure what we should do about it? Just better documentation?
>
> I guess the opened question in my mind is exactly which types need/not
> be adapted? For o
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() method adapts the parameters, that's right.
query() and query_prepared() pass them as strings.
You need
Uploaded everything to PyPI now:
https://pypi.org/project/PyGreSQL/#files
The Windows binaries are here as well:
https://www.vex.net/~cito/distrib/
@D'Arcy - you still need to copy the Windows binaries
from there to http://pygresql.org/files/
-- Christoph
Am 19.05.2019 um 19:23 schrieb Justin Pryzby:
> I think `` should be double-quoted to avoid blowing up if multiple
> "words" are output (I realize that shouldn't happen in this case):
Right, that's a bit more robust and works under Linux and BSD - the
backticks are executed inside double
Am 19.05.2019 um 19:23 schrieb Justin Pryzby:
> I think you handle d and f together as:
>
> |chmod +Xr
The plus sign only adds permissions. We also want to remove permissions
- like when everything is set to 777. This comes close:
chmod -R u=rwX,g=rX,o=rX *
But it's not exactly the same
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 docs/make.bat
chmod 755 mktar mkdocs setup.py
# Make sure file permissions have been set
if [ -z
Am 19.05.2019 um 17:39 schrieb D'Arcy Cain:
> The stat(1) command itself fails. There is no --printf option.
Looks like this works only under Linux. BSD has "stat -f" instead. Let
me see if I can come up with something OS independent.
-- Christoph
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 to checking the permissions, we could add the
following lines that just
These lines check that the permissions are set correctly before building
the source distribution, using a control sample of files. They were
added to prevent building a source tarball with bad permissions, which I
think happened once when I was using a vboxsf filesystem and everything
had 777
Am 19.05.2019 um 14:32 schrieb D'Arcy Cain:> I just did an update and
two files were modified but I did not see any
> extra files. What's missing? Are they still missing?
Now it looks good.
I had added some files to the Manifest.in that are needed to build the
docs. They were missing in
Am 17.05.2019 um 22:16 schrieb D'Arcy Cain:
On 5/17/19 6:52 AM, D'Arcy Cain wrote:
I just rebuilt the site and tar file just in case I missed an update.
I will rebuild again tonight due to the changes just committed.
As far as I see the site has been updated, but the tarballs are still
old
Am 17.05.2019 um 12:52 schrieb D'Arcy Cain:
I think that we are ready now. I haven't seen any other issues for a
few days. Anyone see a reason not to announce?
I just rebuilt the site and tar file just in case I missed an update.
Just noticed a small problem with the source tarballs - they
Am 15.05.2019 um 16:04 schrieb D'Arcy Cain:
We obviously rushed into the release. I wonder if I shouldn't just
remove the two new tags antil we are sure that everything is OK. I
can put both versions up so that they can be checked on the web
Thanks Justin and D'Arcy for noticing and fixing
Am 13.05.2019 um 17:22 schrieb Justin Pryzby:
Checking back about this.
I'm now running this in production at a few customers, including use of
query_prepared(). In one instance I looked at, this is loading 2.7x faster.
From my side everything is fine too.
@D'Arcy - can you create the
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 forgotten something that should be included in the release.
Thanks to
Am 22.04.2019 um 21:15 schrieb Justin Pryzby:
> I suggest that single() should return None for n==0,
> and MultipleResultsFoun> for n>1.
Actually I already added a one() method that is sloppy and returns None.
The single() method is the opposite and considered to be very strict,
when you
Am 22.04.2019 um 20:35 schrieb Justin Pryzby:
> Isn't it a best-practice to make a subclass of ProgrammingError just
Maybe in this case also better a subclass of DataError?
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
For the records, this feature ("iterators as pseudo-cursors") has now
finally been committed in r978 and will be available in PyGres 5.1.
Thanks to Justin for the discussion and implementation. I have only made
a few minor changes and added some missing methods for dicts and named
tuples,
Am 20.04.2019 um 01:20 schrieb Justin Pryzby:
Also, caching the types of the values works
only if you have very few different values (like in your case only a
zero), but for most real-world examples with different strings or floats
this will not work.
Do you mean "..works only if you
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
Am 21.01.2019 um 22:41 schrieb Justin Pryzby:
> -- 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
Am 12.01.2019 um 17:58 schrieb Justin Pryzby:
I realized that the pygres documentation talking about "regular types" is
actually referring to ::regtype, which I think (?) might actually stand for
"registered type" (reg class, regrole, etc).
Right, regtype probably stands for "registered type"
Thanks for the heads up, Justin. It's fixed now.
-- Christoph
___
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
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
and apply your best judgement and standards :)
Ok, thank you. See last commit message.
-- Christoph
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
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
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
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
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
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
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 opi
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):
>
> name=kwargs.get('name', '')
>
> So one *has* to pass name as named param.
For prepare() we don't need that
Am 03.01.2019 um 22:58 schrieb Christoph Zwerschke:
Am 03.01.2019 um 22:52 schrieb Justin Pryzby:
>>
One thought ; should "name" be an kwarg with default name='' ?
Yes, that's a good idea. The parameters would then go in opposite order
to the underlying libpq method, but
Am 03.01.2019 um 23:40 schrieb Justin Pryzby:
> Just a nitpick:
>
> + If you pass no parameters or pass an empty name, then the last unnamed
> + statement will be executed.
>
> + the prepared statement with the given name. If you do not specify a
> + name, then the last unnamed statement will be
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.
> And it's more important for us that there be some method at all
> than that it uses %s. :)
Right, we
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, command):
>
> One thought ; should "name" be an kwarg with default name='' ?
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)")
>
> My first thought is to ask why not use %s parameters ?
Because the $
Am 02.01.2019 um 17:17 schrieb D'Arcy Cain:
> On 1/2/19 8:30 AM, Justin Pryzby wrote:
>> This isn't just a typo, isn't this wrong??
>> days += 365 * years + 30 * mons
> It's certainly inexact. How would you fix that given that we don't
> have the start date?
The problem here is that this
1 - 100 of 413 matches
Mail list logo
