Re: [PyGreSQL] broken parsing of array bounds

A corrupted record at a customer exposed this bug. Arrays with nondefault bounds fail if either bound begins with 0 or 9. Thanks Justin, that definitely looks like a bug. I've created a GitHub issue and will add a regression test and fix after the holidays. -- Christoph

Re: [PyGreSQL] trac#16: PQexecParams resultFormat binary?

Am 14.12.2018 um 15:11 schrieb Justin Pryzby: > I doubt it's easily possible, but what would it take to receive data > in binary format ? Yes, it's not so easy: "Values passed in binary format require knowledge of the internal representation expected by the backend. For example, integers must

Re: [PyGreSQL] prepared statements and EXECUTE parameters

Am 14.12.2018 um 14:57 schrieb Justin Pryzby: > Maybe it's easier than that.. > I saw two issues. First, EXECUTE %s wasn't "adapted" to $1 (since > there were no parameters passed). > Second, execute failed with inline=False. > But actually, SQL EXECUTE doesn't accept parameters, > they MUST be

Re: [PyGreSQL] prepared statements and EXECUTE parameters

Am 14.12.2018 um 01:55 schrieb Justin Pryzby: > Do you have any idea what the interface would look like for this ? > Would we add a prepare() and execute() ? > Or query(..., prepare='name') ? I'd prefer the former. We could then also add describe_prepared() and delete_prepared() (which would

Re: [PyGreSQL] prepared statements and EXECUTE parameters

Am 13.12.2018 um 23:03 schrieb Justin Pryzby: BTW, are the mailing list archives (still) public ? I can't find them and the link is dead. D'Arcy, can you have a look? They're on your server. -- Christoph ___ PyGreSQL mailing list PyGreSQL@vex.net

Re: [PyGreSQL] prepared statements and EXECUTE parameters

Hi Justin, unfortunately PyGres does not yet support prepared statements with parameter passing. I think this can only be solved by adding support for PQExecPrepared in the C module. I have now added a ticket for this: http://trac.pygresql.org:8000/pgtracker/ticket/76 -- Christoph

Re: [PyGreSQL] Bug in driver

Am 17.07.2018 um 21:54 schrieb M P: I said before I have tried in a single threaded test case with the same issue. That makes it all the more mysterious, and as I said, if you can provide a reproducible test case that creates this kind of low-level network protocol error without threads or

Re: [PyGreSQL] Bug in driver

Am 12.07.2018 um 00:59 schrieb M P: I've used this in a single threaded program and it had this error. I swapped with another python pgsql driver and used the same exact queries without an issue. We'd be glad if you could provide a reproducible single threaded test case for this issue if you

Re: [PyGreSQL] Bug in driver

Am 29.06.2018 um 22:40 schrieb M P: > I may have found a bug in the driver. See the SO post here: > > https://stackoverflow.com/questions/51108552/pygresql-insufficient-data-in-t-message See my reply on SO. I don't think it has anything to do with PyGreSQL, and without a reproducible test

Re: [PyGreSQL] PyGreSQL 5.1

Am 08.07.2018 um 19:23 schrieb Justin Pryzby: Memory use should be a nonissue for iterators, right? Right, the switch to iterators makes it less necessary to have different methods for different result types. The question is then which type we should use as the row type for the iterator. It

Re: [PyGreSQL] PyGreSQL 5.1

I'm also considereing to de-support some of the old Python and Postgres versions (Python 2.6 and 3.3, Postgres 9.0, 9.1, 9.2) for version 5.1.x. Thoughts? -- Christoph ___ PyGreSQL mailing list PyGreSQL@vex.net

[PyGreSQL] PyGreSQL 5.0.6 and 5.1

Here are some thoughts on the next steps in PyGreSQL development. First, even though there haven't been any real changes, we should release a 5.0.6 version that ships with binaries for Python 3.7 and the proper trove classifier for the license. The problem with 5.0.5 was that we couldn't

Re: [PyGreSQL] Possible bug in PyGreSQL for Unicode and Python 2.x

Am 25.04.2018 um 19:22 schrieb Murray Chapman: > Thanks for the reply! I understand your reasoning, and since there's a > few workarounds it's not really an issue for me any more, but there's a > few extra things I wanted to note: Thanks for explaining. We need such feedback. Regarding Django,

Re: [PyGreSQL] Possible bug in PyGreSQL for Unicode and Python 2.x

Am 25.04.2018 um 03:31 schrieb Murray Chapman: > I'm seeing some unexpected behavior with PyGreSQL running under Python > 2.x when reading utf8-encoded data from the db. > > Basically, PyGreSQL/Python2.x always seems to return it as a str() > rather than a unicode(). That's a feature, not a bug.

Re: [PyGreSQL] PostgreSQL 10 ETA?

Am 20.03.2018 um 12:34 schrieb Leonard, Arah: > Is there any indication when PostgreSQL 10 will be supported As soon as D'Arcy creates a 5.0.5 tag and bugfix release from the 5.0.x branch in SVN. But you can already use 5.0.4 with Postgres 10, there have been no code changes for Postgres 10,

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Am 22.04.2018 um 14:01 schrieb Christoph Zwerschke: > * Would it make sense to make the result row type configurable by > providing get/set_result_type() methods on the module, connection and > query level? We could then get rid of the 6 different accessor methods > for the result

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Am 26.03.2018 um 22:01 schrieb Justin Pryzby: > I have one patch ready for evaluation. > > 1: implement fake/pseudo cursors in pg (same as what's in pgdb); > I proposed not to support any "move()" function in pg, since > there's no "fetch" (besides getItem which is newly introduced > at your

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Am 26.03.2018 um 22:01 schrieb Justin Pryzby: > I have one patch ready for evaluation. > > 1: implement fake/pseudo cursors in pg (same as what's in pgdb); I proposed not > to support any "move()" function in pg, since there's no "fetch" (besides > getItem which is newly introduced at your

Re: [PyGreSQL] use-after-free bug in query function implementation

Hi Peifeng, thank you for the bug report and the patch. I can confirm your analysis and patch are correct and will fix this today in the trunk and the branches. -- Christoph Am 22.01.2018 um 05:10 schrieb Peifeng Qiu: > Hi, developers. > > db.query for insert query should return the success

Re: [PyGreSQL] DLL load failed at w32

Am 17.08.2017 um 06:36 schrieb Oleg Broytman: > I started to experience the problem at AppVeyor CI where all my tests > with 32-bit Pythons (all versions: 2.7 and 3.4+) fail; 64-bit Pythons > are ok. I resurrected my old WinXP in VirtualBox (I am not an active > Windows user), upgraded Python

Re: [PyGreSQL] unescape_bytea("''")

Hi Oleg, Am 26.07.2017 um 23:49 schrieb Oleg Broytman: > Shouldn't unescape_bytea(escape_bytea()) be idempotent? See https://www.postgresql.org/docs/9.6/static/libpq-exec.html "PQunescapeBytea is not exactly the inverse of PQescapeBytea, because the string is not expected to be "escaped"

Re: [PyGreSQL] Time for a bugfix release

Am 28.07.2017 um 16:18 schrieb D'Arcy Cain: >> I decided for the latter and patched it in r902, because I wanted >> Pygres to behave the same in all Postgres versions and because this >> is what you expect from a "host" attribute. (We could add another >> attribute for getting the socket, if

Re: [PyGreSQL] Time for a bugfix release

Am 27.07.2017 um 15:00 schrieb Pavel Raiskup: Turns out there's probably a new test that checks that the testsuite runs through localhost IP, but historically I used the 'psql -h /tmp' like connection through socket. Hi Pavel, thanks for the feedback. The problem here is caused by a change in

Re: [PyGreSQL] Time for a bugfix release

Ok, the 5.0.4 release is now on PyPI and the Windows binaries are also at https://www.vex.net/~cito/distrib/ @D'Arcy, you can also copy them over to http://www.pygresql.org/files/? -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net

Re: [PyGreSQL] Time for a bugfix release

Am 26.07.2017 um 14:56 schrieb Justin Pryzby: > Is there anything else needed to make it available in pip ? No, I just got sidetracked by other problems. I'll create the Windows binaries and publish on PyPI today. -- Chris ___ PyGreSQL mailing list

Re: [PyGreSQL] Time for a bugfix release

Am 08.07.2017 um 12:26 schrieb Christoph Zwerschke: There have been several small fixes after version 5.0.3, including one issue that prevented compilation under OS X. Time to cut a 5.0.4 bugfix release. @D'Arcy, can you do that? The changelog is ready, only the release date must be specified

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Am 09.07.2017 um 19:07 schrieb Justin Pryzby: Could you elaborate on that ? I would like the idea of a standard function, returning its length, the same thing as ntuples(), but how would one call it ? It seems len() function only works for sequences and mappings. If you implement a __len__

[PyGreSQL] Time for a bugfix release

There have been several small fixes after version 5.0.3, including one issue that prevented compilation under OS X. Time to cut a 5.0.4 bugfix release. @D'Arcy, can you do that? The changelog is ready, only the release date must be specified. The pseudo-cursor feature suggested by Justin can

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Am 05.07.2017 um 23:12 schrieb Justin Pryzby: I'm hoping for some feedback on this - if the interface seems okay and the implementation otherwise fine, I can clean up some by pulling out the duplicated code from queryGet/Dict/Result and queryNext(). Hi Justin, some quick feedback: * The

Re: [PyGreSQL] pg.DB() pseudo-cursor to reduce RAM use

Hi Justin, thanks for your contribution. I'll look at this when I find some. Might take 2 or 3 weeks though.-- Chris___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] Compile issue with Advance Toolchain

Am 26.05.2017 um 11:00 schrieb Devrim Gündüz: I'm not familiar with Python, but AFAICS it uses get_default_compiler() to find the compiler. However, since I want to use GCC that comes with AT, I would like to override the output of this function. Any suggestions how I can do it? You should try

Re: [PyGreSQL] German Wikepedia page

The article is essentially correct, but not very useful. It describes some uninteresting internals like names of C objects which have been changed in 5.x anyway. It doesn't mention the newer high-level methods and newer features. It also fails to mention some fundamental things like being

Re: [PyGreSQL] pygres 5.0.3 namedtuple refuses underscores

Am 06.01.2017 um 14:10 schrieb Justin Pryzby: Heh - were there any changes needed ? We're on top of that one at least - have been running PG96 + pygres5 for months on 40 servers. Probably no changes will be needed, but the CI (https://travis-ci.org/Cito/pygresql/) does not yet test against

Re: [PyGreSQL] pygres 5.0.3 namedtuple refuses underscores

Am 03.01.2017 um 21:27 schrieb Glyph Lefkowitz: This is a little off-topic, but if you're OK with using a version of Python that has been officially end-of-lifed , why are you doing new software development on it? Why not

Re: [PyGreSQL] pygres 5.0.3 namedtuple refuses underscores

Am 02.01.2017 um 14:42 schrieb Justin Pryzby: Yes, unfortunately we're still using py 2.6. I have now committed a patch to the trunk that makes the auto renaming more accurately in Python 2.6, please check it out. -- Christoph ___ PyGreSQL mailing

Re: [PyGreSQL] pygres 5.0.3 namedtuple refuses underscores

Am 02.01.2017 um 14:42 schrieb Justin Pryzby: The somewhat overly-restrictive behavior checking for isalnum() should only be used with old Python versions (2.6 and 3.0). Do you use one of these? Then my suggestion is to document the change and make the check more specific for Py 2.6 and 3.0.

Re: [PyGreSQL] pygres 5.0.3 namedtuple refuses underscores

Am 02.01.2017 um 03:15 schrieb Justin Pryzby: After instaling the latest version, I discovered that our singular use of namedresult() is broken, following the pygres implementation of LRU cache, since our field names includes underscores, which are not "isalnum()". You're right, that was a

Re: [PyGreSQL] query_formatted without params

Am 31.12.2016 um 17:16 schrieb Justin Pryzby: trunk works, thanks. Ok, this will then go into the next version. Thanks for your feedback this year and have a good new year! -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net

Re: [PyGreSQL] query_formatted without params

Am 31.12.2016 um 16:58 schrieb Justin Pryzby: I retried in 5.0.3: It's not yet in 5.0.3, only in the trunk. You must check it out with svn co svn://svn.pygresql.org/pygresql/trunk and then do a python setup.py install. -- Christoph ___ PyGreSQL

Re: [PyGreSQL] query_formatted without params

Am 31.12.2016 um 16:01 schrieb Justin Pryzby: > Traceback (most recent call last): > File "/tmp/tpy", line 11, in > print db.query_formatted( > 'SELECT * FROM sites WHERE site_geo IS NOT NULL').getresult()[0] > File "/usr/lib64/python2.6/site-packages/pg.py", line 1750, > in

Re: [PyGreSQL] query_formatted without params

Am 31.12.2016 um 00:00 schrieb Justin Pryzby: It seems to me you can just do: def query_formatted(self, command, parameters=[], types=None, inline=False): This would work, but I always try to avoid using mutable objects as default parameters, and use None as placeholder for "nothing". I

Re: [PyGreSQL] Connection strings & SSL

Am 25.11.2016 um 21:45 schrieb Patrick TJ McPhee: On Tue, 22 Nov 2016 12:45:40 +0100, Christoph Zwerschke wrote: This should also work with the DB API 2 module, right? It does, but it's the database argument, which is not first in the list, so you need something like this: Thanks

Re: [PyGreSQL] Connection strings & SSL

Am 21.11.2016 um 22:06 schrieb Patrick TJ McPhee: A while ago Chris was reflecting on adding support for libpq connection strings, and we ("we") have Ticket #62 to add SSL support. I've been meaning to point out these both work OK today. Passing connection strings in the dbname parameter works

Re: [PyGreSQL] Ticket #49 - new patch for asynchronous connections and queries

Am 21.11.2016 um 21:32 schrieb Patrick TJ McPhee: I submitted a patch a while ago to support asynchronous connections and queries (Ticket #49). At roughly the same time, D'Arcy started checking in changes to support python 3, so the patch didn't work any more. I've had my head under water since

Re: [PyGreSQL] PygreSQL on linux Debian

Am 09.11.2016 um 15:02 schrieb Justin Pryzby: I'm sure recent pygres works fine under all linux OS; you might try installing the latest version using PIP. Yes, that should work - otherwise please let us know. -- Chris ___ PyGreSQL mailing list

Re: [PyGreSQL] sql array notation parsing bug in pygresql-5+

Hi Raf, thanks again for your feedback regarding arrays and performance. In the trunk, you can now change the array cast function. Also, the namedtuple classes are now cached for better performance. If possible, check out the trunk and let me know if it works for your. We will then create a

Re: [PyGreSQL] sql array notation parsing bug in pygresql-5+

Am 20.09.2016 um 02:29 schrieb raf: Christoph Zwerschke wrote: I think so. But it may point to a performance degradation elsewhere, so I'd like to check this. Did you forget to attach the test? Oops. Sorry about that. Here it is. Thanks a lot. I had a look at this and can confirm

Re: [PyGreSQL] sql array notation parsing bug in pygresql-5+

Am 15.09.2016 um 04:34 schrieb raf: >> The question for me is not how frequently arrays are used, but how >> frequently arrays with non-default start indices are used. Note that the >> ARRAY constructor in Postgres doesn't even have a way to set a different >> start index (as far as I know). > >

Re: [PyGreSQL] sql array notation parsing bug in pygresql-5+

Am 13.09.2016 um 08:35 schrieb raf: I suspect that if people aren't complaining about it, that might be because array columns probably aren't a very popular datatype in sql databases. The only reason I'm using them is because it was the easiest and quickest way to migrate data from a database

Re: [PyGreSQL] infinite recursion in pg getattr

Am 07.09.2016 um 21:33 schrieb D'Arcy J.M. Cain: > Seems like overkill. A class variable effectively does all of that in > one line by making sure that it is always set. Ok, so I committed this as the fix together with a regression test. We should probably release a 5.0.2 since this is a

Re: [PyGreSQL] infinite recursion in pg getattr

Am 07.09.2016 um 17:02 schrieb Justin Pryzby: Here's a minimal test: Thanks, that was helpful. As already suspected, the error happens because in the DB.__init__ method an exception is raised when creating the lower level connection because there are already too many, and this happens

Re: [PyGreSQL] pygresql-5 backwards-incompability: TypeError: 'Row' object does not support item assignment

Am 24.08.2016 um 04:23 schrieb r...@raf.org: A possibly unintentional backwards-incompability with pygresql-5+. Assigning to an element of what used to be a list but is now a Row object, for example: r[4] = None results in: TypeError: 'Row' object does not support item assignment Can

Re: [PyGreSQL] how to suppress timestamptz conversion to datetime.datetime [SOLVED]

Am 29.08.2016 um 04:40 schrieb raf: What does work (lucky guess) is using str() as the typecast function: pgdb.set_typecast('timestamptz', str) # Python2 at least Right, that's how you can access the raw data. Or alternatively, pgdb.set_typecast('timestamptz', lambda v: v) This works

Re: [PyGreSQL] sql array notation parsing bug in pygresql-5+

Am 23.08.2016 um 06:57 schrieb raf: Here's a little program to demonstrate: #!/usr/bin/env python import pgdb connection = pgdb.connect(host='XXX', database='XXX', user='XXX', password='XXX') cursor = connection.cursor() cursor.execute("select cast('[2:2]={1}' as integer[])") rows

Re: [PyGreSQL] infinite recursion in pg getattr

Am 30.08.2016 um 19:22 schrieb Justin Pryzby: I believe this is triggering infinite recursion: pg.py class DB: def __getattr__(self, name): # All undefined members are same as in underlying connection: if self.db: return getattr(self.db, name) "if self.db"

Re: [PyGreSQL] pygresql-5 backwards-incompability: TypeError: 'Row' object does not support item assignment

Unfortunately I'm currently more or less offline but I'll look into that next week when I'm in the office again. -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] pygresql-5 backwards-incompability: TypeError: 'Row' object does not support item assignment

The default row type has been changed because a tuple is considered the more appropriate, pythonic type for an inhomogeneous collection where the order matters. This is also what most other drivers deliver and people expect. Named tuples are even more convenient. Having said this, you can also

Re: [PyGreSQL] Named arguments in classic interface

Am 18.08.2016 um 16:51 schrieb D'Arcy J.M. Cain: All good ideas but not what I meant. I can do this in pgdb: Q = "SELECT * FROM artran WHERE glaccount = %(glaccount)s AND trdate > %(trdate)s" x = dict(trdate = "jan 1 2016", glaccount = "1140-") res = con.execute(Q, x) I would like to

Re: [PyGreSQL] Named arguments in classic interface

Am 17.08.2016 um 18:41 schrieb D'Arcy J.M. Cain: It seems that we support positional arguments. How hard would it be to port named arguments from the DB-API interface to the classic one? The C module and the DB wrapper take named arguments as well, they only have different names (dbname <>

Re: [PyGreSQL] pygres pg: =ANY(%s) fails with empty list

Am 04.08.2016 um 20:05 schrieb Justin Pryzby: A coworker pointed out that this doesn't work: a=[] pg.DB().query_formatted("select 1 where 1 = any(%s)", [a] ).getresult() Thanks for reporting. I just fixed it in the trunk. -- Christoph ___ PyGreSQL

Re: [PyGreSQL] pg.DB() mem leak

Am 23.07.2016 um 14:24 schrieb Christoph Zwerschke: The problem is that we need to clean up using a destructor in that case. However, since there are circular references, destructors do not work. So we need to make some changes, like using weak references. I'll experiment with that idea later

Re: [PyGreSQL] pg.DB() mem leak

Am 22.07.2016 um 21:33 schrieb Justin Pryzby: I discovered that pg.DB() leaks, while pg.connect() doesn't. I have added tests for this to the test suite now, and fixed the problem in the case where the connection is closed. Your test program works now, the memory does not increase any more.

Re: [PyGreSQL] pg.DB() mem leak

Am 22.07.2016 um 21:33 schrieb Justin Pryzby: I discovered that pg.DB() leaks, while pg.connect() doesn't. Thanks, I'll look into that tomorrow. Your clues and test code are already very helpful. Maybe I can also add some tests for such memory leaks into the test suite. -- Chris

Re: [PyGreSQL] query_formatted requires all dict keys to be referenced?

Am 20.07.2016 um 17:56 schrieb Justin Pryzby: This was an issue while converting existing application from pg.connect().query() to DB.query_formatted. The previous query used % string interpretation, which allows passing a dict with "extra" values. Right, passing extra values was not allowed.

Re: [PyGreSQL] pygres failing to cast to python type due to int overflow?

Am 14.07.2016 um 00:31 schrieb Justin Pryzby: Problem seems to be here: cast_other (s=0x68ebac "010100713D0AD7A3A054C04260E5D022BB4240", size=42, encoding=6, pgtype=-799870613, cast_hook=0x2f70f230) /* Cast an arbitrary type to a Python object using a callback function. This needs

Re: [PyGreSQL] pygres failing to cast to python type due to int overflow?

Ok, thanks for the info. I'll look into that later this week. -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] pygres failing to cast to python type due to int overflow?

Am 13.07.2016 um 22:56 schrieb Justin Pryzby: $ python -V Python 2.6.8 This is also 64bit I assume (you see it when you just type "python")? -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] pygres failing to cast to python type due to int overflow?

Am 13.07.2016 um 22:25 schrieb Justin Pryzby: I'm converting our application from using pg.connect().query pg.DB().query_formatted(), and ran into an issue involving .dictresult() with a column of postgis type "geometry". I see in the logs pygres attempting to convert to python type, and

Re: [PyGreSQL] Supporting Communication with older Postgresql servers

Am 06.07.2016 um 03:31 schrieb Andres Mejia: I have a patch which enables communication with Postgresql servers running v8.0. See attached. Hi Andres, thanks for the patch. The modern 5.x versions actually are meant to support only Postgres 9.x (and are tested only against it). We maintain

Re: [PyGreSQL] application_name parameter

Am 29.06.2016 um 16:35 schrieb Stanisław Skonieczny: Hello. We wanted to use pygresql in our project (together with sqlalchemy), Btw, you should use SQLAlchemy >= 1.1 (currently still in beta), since the older versions do not support PyGreSQL very well. -- Christoph

Re: [PyGreSQL] Get rid of get

Am 05.05.2016 um 12:03 schrieb D'Arcy J.M. Cain: > It does occur to me now that doing this only makes sense if you are > also creating specialized methods for managing the data so I guess it > doesn't hurt if I keep doing it in my own subclasses. There's no real > benefit to doing this in a raw

Re: [PyGreSQL] Get rid of get

Am 04.05.2016 um 07:34 schrieb D'Arcy J.M. Cain: > If data is None use self for the dictionary. > > db = DB() > db['table_id'] = key > db.select('table) > > Thoughts? I would find it a bit confusing since the db instance would then combine two different responsibilities in one object,

Re: [PyGreSQL] Problems installing PyGreSQL on Windows

Am 04.05.2016 um 20:51 schrieb Magnus Lind Oxlund: Yes, I'm ‎running PostgreSQL version 9.5.2-1 64-bit. Does Python find the libpq library? You can check it like this: import os for path in os.environ['PATH'].split(';'): print(path) if 'libpq.dll' in os.listdir(path):

Re: [PyGreSQL] Problems installing PyGreSQL on Windows

Am 04.05.2016 um 20:27 schrieb Magnus Lind Oxlund: I happen be running in a virtual environment (pyvenv) in which I have installed PyGreSQL through pip. PostgreSQL 9.5 is installed on my machine, and I have made sure to add both the PostgreSQL bin and lib folders to my Path variable as advised

Re: [PyGreSQL] Exception catching in Classic PyGreSQL module pg?

You can also query SQLSTATE like this: with pg.DB() as db: try: db.query("SELECT * FROM NoSuchTable") except pg.DatabaseError as e: print("ERROR: SQLSTATE={}".format(e.sqlstate)) This should print "ERROR: SQLSTATE=42P01" (undefined_table). -- Christoph

[PyGreSQL] Minor twist in update() in 5.0

Just committed a change to the update() method in the classic module that fixes a small backward compatibility/usability issue in the current version 5.0: In the case that both an OID and a primary key is provided in a row dictionary, the OID now takes precedence again when looking up the row,

Re: [PyGreSQL] Release 5.0 of PyGreSQL

Am 21.03.2016 um 14:50 schrieb Pavel Raiskup: .. which is OTOH different. I would also fix the link from your homepage, the link should point to versioned tarball (to make 100% clear what is the latest released tarball). I second that. The file name should contain the version number, in the

Re: [PyGreSQL] Release 5.0 of PyGreSQL

Am 21.03.2016 um 20:30 schrieb Pavel Raiskup: There is just one issue if I build the PyGreSQL package on my box (CEST timezone): I noticed the same problem today when compiling under windows, and simply solved it by setting the timezone to utc in the test. -- Chris

Re: [PyGreSQL] Regression on 4.2.1: db.insert('temp_table', d) fails

Am 16.03.2016 um 22:59 schrieb Patrick TJ McPhee: I haven't had time to work up a unit test, and I haven't checked against trunk, yet, but it's no longer possible to db.insert() into a temp table in 4.2.1, and presumably beyond. Thanks for reporting. As you already noticed, the problem is a

Re: [PyGreSQL] Regression on 4.2.1: db.insert('temp_table', d) fails

Ok, committed the changes. Time to release 5.0 and 4.2.2. :) -- Christoph ___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] Releasing 5.0

Am 15.03.2016 um 16:42 schrieb D'Arcy J.M. Cain: Should I branch 5.x or simply tag 5.0 on the trunk? We can create the branch later when we really plan to work on features that should go in a 6.x. For now, 5.x can stay in the trunk. -- Christoph

Re: [PyGreSQL] Release 4.2.1

Windows binaries for version 4.2.1 are now on PyPI at https://pypi.python.org/pypi/PyGreSQL/4.2.1 and also at http://www.vex.net/~cito/distrib/ -- Chris ___ PyGreSQL mailing list PyGreSQL@vex.net https://mail.vex.net/mailman/listinfo.cgi/pygresql

Re: [PyGreSQL] PyGreSQL Commit r853 - tags/4.2.1

Am 18.02.2016 um 19:41 schrieb D'Arcy J.M. Cain: Done. I will tag 5.0 in a few days. I don't think that we need to make a big announcement for 4.2.1. No, that's not necessary. I'll add it to PyPI and add a short notice to the changelog tomorrow. Before announcing 5.0 please let me know so

Re: [PyGreSQL] PyGreSQL Commit r853 - tags/4.2.1

Am 18.02.2016 um 18:29 schrieb D'Arcy J.M. Cain: After these changes I need to re-tag. Should I remove the 4.2.1 tag and re-copy or just tag 4.2.2? If it's not yet released, it's not problem in Subversion to make the changes to a tag (there's actually no difference between a tag and a

Re: [PyGreSQL] Release 4.2.1

Am 17.02.2016 um 18:01 schrieb D'Arcy J.M. Cain: I am about to tag current 4.x as 4.2.1. Any last minute updates? Nothing from my side. In about a week I will tag the trunk as 5.0. Or, should I branch 5.x and tag that? Do we have any features for 6.x that we want to start on now? No, we

Re: [PyGreSQL] Current status

Am 09.02.2016 um 23:15 schrieb Ross Reedstrom: Have more than one choice at any point in an software ecosystem usually leads to both choices getting better. Yes, that's also my experience. When everybody relies on a certain software, there is little room for experimentation, you start to

Re: [PyGreSQL] Current status

Today I've closed the last open ticket for 5.0: SQLALchemy support. The complete SQLAlchemy test suite now works against a postgresql+pygresql database URL, with Python 2 and Python 3, in addition to our own test suite which has become pretty extensive. This makes me quite confident regarding

[PyGreSQL] Current status

Current status of the upcoming 5.0 version: I have completed everything that was on the roadmap for 5.0, all test pass in many configurations, also added tox and Travis files so these tests can be automated. Here is a list of all the tickets:

Re: [PyGreSQL] PyGreSQL Commit r838 - trunk

Am 07.02.2016 um 17:27 schrieb D'Arcy J.M. Cain: Next release should become 5.0b1 instead of 5.0a0. Not sure that I understand. Wouldn't the next release be 5.1? We have never used letters before. 5.0a0 = alpha pre-release of 5.0, 5.0b1 = first beta release of 5.0 I am using the notation

Re: [PyGreSQL] 4.2 release tarball question

Am 26.01.2016 um 04:19 schrieb Mikhail Terekhov: I've downloaded the release tarball from http://www.pygresql.org/files/PyGreSQL-4.2.tar.gz and noticed that all files have the executable permission set for user and group. Is it intentional? No, this is an accident. It can happen if the source

Re: [PyGreSQL] 4.2 release tarball question

Hi Mikhail, thanks for testing. I am mainly interested in experiences with real-life applications, particularly when updating from 4.x to 5.x. While making Pygres much more powerful with lots of new features, I still want to make updating as smooth as possible and not break anything for

Re: [PyGreSQL] 4.2 release tarball question

Am 26.01.2016 um 16:41 schrieb Mikhail Terekhov: Also I've noticed that tarball is missing from pypi. Sadly, yes. I tried to re-upload a corrected tarball - PyPi was happy to delete the old one, but doesn't allow undoing this operation or uploading a new one, even if it has the same content.

Re: [PyGreSQL] PyGreSQL Commit r779 - branches/4.x/docs trunk/docs

Am 22.01.2016 um 21:05 schrieb D'Arcy J.M. Cain: Even if they are correct changes I think we have to draw a line at some point. I just tagged 4.2 yesterday and already we have to look at 4.2.1. Let's just make these types of changes to the trunk unless it is a debilitating bug. Yes, we

Re: [PyGreSQL] What have we tested on?

Am 02.01.2016 um 17:09 schrieb Christoph Zwerschke: I'll try to run some more tests on older Postgres versions and 32 bit Python today. Ok, I have successfully tested the 4.x branch on an old 32bit openSUSE 11.0 with Python 2.5 and Postgres 8.3 now. Some tests assumed Postgres 9.x, so I

Re: [PyGreSQL] Getting ready for 4.2

Am 23.12.2015 um 06:05 schrieb D'Arcy J.M. Cain: > Everything seems OK except that the dbapi test doesn't seem to be > looking at LOCAL_PyGreSQL.py. It works for me, except for the port which is ignored, because the connection is passed as a dsn and currently PyGreSQL does not provide a way to

Re: [PyGreSQL] PyGreSQL Commit r666 - branches/4.x/module/tests

Am 23.12.2015 um 16:14 schrieb da...@pygresql.org: When creating a missing database use the same parameters... Ok, now I see what your issue was ;) -- Christoph ___ PyGreSQL mailing list PyGreSQL@vex.net

Re: [PyGreSQL] Getting ready for 4.2

Am 22.12.2015 um 12:15 schrieb D'Arcy J.M. Cain: > error: invalid command 'test' You probably forgot to install setuptools. For Python 2.6 you also need to install unittest2. I have some time over the holidays again, so if needed I can help. -- Christoph

Re: [PyGreSQL] Insert and update should handle bytea

Am 10.12.2015 um 07:25 schrieb D'Arcy J.M. Cain: Shouldn't it? Here is a test that I think should pass but currently does not. Since DB adapts other types on ingress of insert() and update() as well, that makes sense. Your patch missed adding the bytea check in the _quote method. The test

Re: [PyGreSQL] Insert and update should handle bytea

Am 10.12.2015 um 07:25 schrieb D'Arcy J.M. Cain: It should also handle the get method so that we don't need the unescape. Done in r664. The methods now encode incoming bytes to bytea to bytes and decode outcoming bytea to bytes automatically. Note that this is currently done on the DB

Re: [PyGreSQL] Moving to Sphinx

Am 05.12.2015 um 16:52 schrieb D'Arcy J.M. Cain: Here is what it looks like with no changes to the files other than the above config change and renaming index.rst to index.txt. http://darcy.vex.net/PyGreSQL_docs/ That looks nice! If you can transfer the remaining info from the old index.html

<    1   2   3   4   5   >