From noreply at pgfoundry.org Sun Jan 6 05:25:41 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Sun, 6 Jan 2008 05:25:41 +0000 (UTC) Subject: [ python-Bugs-1000301 ] Cajole epydoc or other into giving output suitable for forrest Message-ID: <20080106052541.2644717AD103@pgfoundry.org> Bugs item #1000301, was opened at 2005-04-28 01:55 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000301&group_id=1000094 Category: Documentation Group: To do >Status: Closed Resolution: Accepted Priority: 2 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Cajole epydoc or other into giving output suitable for forrest Initial Comment: Serving up the HTML output from epydoc is fine, but it is not seamless. Having it generate Apache Documentation 2.0 or DocBook 5.0 would give something that could be worked with. The API reference should have a seperate section from the documentation on the site, as the documentation is meant to be official. Also, the current infrastructure there on /web depends on the docs being specially generated from /doc. ---------------------------------------------------------------------- >Comment By: James Pye (jwp) Date: 2008-01-05 22:25 Message: I'm not going to use forrest for the module documentation. It seems more painful than useful. I'm thinking about just doing raw uploads of generated pydoc html into a directory structure: http://python.projects.postgresql.orgs/docs/pg_proboscis/0.9/postgresql.interface.proboscis.greentrunk Something simple. :) ---------------------------------------------------------------------- Comment By: James Pye (jwp) Date: 2006-02-12 22:13 Message: The appendix portion of the documentation is a fantastic place for reference material. Currently, the data there was entered by hand. This is painful and unnecessary. However, each section will likely need a custom generator to suite the specific aspects of the objects. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000301&group_id=1000094 From noreply at pgfoundry.org Sun Jan 6 05:35:58 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Sun, 6 Jan 2008 05:35:58 +0000 (UTC) Subject: [ python-Bugs-1010221 ] Run interrupt on controller loss tracked by a weakref Message-ID: <20080106053558.904E217AD103@pgfoundry.org> Bugs item #1010221, was opened at 2008-01-05 22:35 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010221&group_id=1000094 Category: FE/Proboscis Group: None Status: Open Resolution: None Priority: 4 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Run interrupt on controller loss tracked by a weakref Initial Comment: With the new protocol transactions, it is possible to assign "controller" objects to a given transaction as a weakref. The weakref is necessary because it is important to know when the interface to the result set no longer exists. When an attempt to process further transactions is made, a check can be done on the weakref to identify if the controller still exists; if it doesn't an exception should be raised and the current transaction interrupted(via .Interrupt()) notifying the user of the potential data/state loss and for large copies interrupting a very costly completion. Normally these situations would occur when an interrupt occurs(signal or keyboardinterrupt). For the most part, this would normally see action on ResultHandles running COPYs, and Portals on the initial execute. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010221&group_id=1000094 From noreply at pgfoundry.org Sun Jan 6 05:39:07 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Sun, 6 Jan 2008 05:39:07 +0000 (UTC) Subject: [ python-Bugs-1010222 ] Validate order of messages Message-ID: <20080106053907.28E5817ADCE5@pgfoundry.org> Bugs item #1010222, was opened at 2008-01-05 22:39 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010222&group_id=1000094 Category: PQ/PQueue Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Validate order of messages Initial Comment: Currently, the client3.Transaction class will not *always* check to make sure messages come in order. Rather, in many situations it merely compares the incoming message to a set of messages. If it's contained in the set it sees it as "Ok", which is wrong. Usually, this does not cause problems, but it does keep the driver from identifying bad backends. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010222&group_id=1000094 From pgsql at jwp.name Tue Jan 8 18:42:29 2008 From: pgsql at jwp.name (James William Pye) Date: Tue, 8 Jan 2008 11:42:29 -0700 Subject: pg_proboscis 0.9 release Message-ID: <20080108184229.GA3948@lit.jwp.name> Yeah, I finally released something. It's just the driver, but it will help pave the future for the PL(API-wise and slythe). :) There are many marked improvements, and I would like to list them all, but it's been a work in progress for some time now, so I forget many of them. And, yes, this breaks things if you use 0.1; so the documentation currently available on the website is mostly invalid. :P + pypi distribution/setuptools build process. + COPY improvments (COPY queries return a ResultHandle object for managing the copy) + simplified type I/O management; now returns standard Python object + Binary timestamp support; (including timestamptz support with pytz package) + Improved array support. + Better interrupt safety. + first() method (~ shorthand) + "Transaction" connection objects for managing transactions. + Improved server settings interface("con.Settings") + "re-connectable" connections; I believe in 0.1 you had to create a new connection. - WireTap has been removed; likely to be replaced in 1.0. Some example performance numbers: jwp at torch[]:pkg/src/lo 0% pg_tin com pb_python -m postgresql.protocol.greentrunk.test.perf_copy_io preparing data(150000 tuples)... starting copy... COPY FROM STDIN Summary, copied tuples: 150000 copied bytes: 8729741 duration: 1.036334 average tuple size(bytes): 58.000000 average KB per second: 8226.112131 average tuples per second: 144740.975913 COPY TO STDOUT Summary, copied tuples: 150000 duration: 0.871910 average KB per second: 9777.386886 average tuples per second: 172036.132899 jwp at torch[]:pkg/src/lo 0% pg_tin com pb_python -m postgresql.protocol.greentrunk.test.perf_query_io INSERT Summary, inserted tuples: 15000 total time: 1.272875 average tuples per second: 11784.345806 SELECT Summary, looped/tuples: 15000 looptime: 0.627941 average tuples per second: 23887.598599 From pgsql at jwp.name Tue Jan 8 18:47:10 2008 From: pgsql at jwp.name (James William Pye) Date: Tue, 8 Jan 2008 11:47:10 -0700 Subject: pg_proboscis 0.9 release In-Reply-To: <20080108184229.GA3948@lit.jwp.name> References: <20080108184229.GA3948@lit.jwp.name> Message-ID: <20080108184710.GA5254@lit.jwp.name> On Tue, Jan 08, 2008 at 11:42:29AM -0700, James William Pye wrote: > Yeah, I finally released something. It's just the driver, but it will help pave > the future for the PL(API-wise and slythe). :) Almost forgot to mention, to install: $ easy_install pg_proboscis However, you will have install the ssl module manually as it doesn't appear to be easy_install friendly per a SandboxViolation that it generates. To correct this, you'll have to download the tar.gz file, extract it, and run setup.py manually. The rest should install quite happily. Hope this is the start of a run to a stable 1.0! From pgsql at jwp.name Tue Jan 8 19:15:33 2008 From: pgsql at jwp.name (James William Pye) Date: Tue, 8 Jan 2008 12:15:33 -0700 Subject: pg_proboscis 0.9 release In-Reply-To: <20080108184229.GA3948@lit.jwp.name> References: <20080108184229.GA3948@lit.jwp.name> Message-ID: <20080108191533.GB5254@lit.jwp.name> On Tue, Jan 08, 2008 at 11:42:29AM -0700, James William Pye wrote: > + first() method (~ shorthand) Figure I should explain this. I find myself frequently needing to run a query where I'm only interested in the first result. So, having an quick way to access this without all the extra characters and objects is needed. # Or Query(...).first() >>> ~GTX.Query("SELECT version()") u'PostgreSQL 8.2.5 on i386-apple-darwin8.10.1, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)' >>> GTX.Query("SELECT version()")().next()[0] u'PostgreSQL 8.2.5 on i386-apple-darwin8.10.1, compiled by GCC i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)' Additionally, this saves you from having to handle StopIteration exceptions on empty result sets. This idiom does create some ambiguity; empty result sets return None and SELECT NULL returns None. However, the convenience is well worth it, IMO. From pgsql at jwp.name Tue Jan 8 23:07:09 2008 From: pgsql at jwp.name (James William Pye) Date: Tue, 8 Jan 2008 16:07:09 -0700 Subject: pg_proboscis 0.9 release In-Reply-To: <010820082041.9605.4783DFE2000775240000258522007507449D0A900E04050E@comcast.net> References: <010820082041.9605.4783DFE2000775240000258522007507449D0A900E04050E@comcast.net> Message-ID: <20080108230709.GA6686@lit.jwp.name> On Tue, Jan 08, 2008 at 08:41:06PM +0000, Adrian Klaver wrote: [CC'ing list] > A couple of questions. > 1) I could not seem to find the new release on pgfoundry. Am I jumping the gun? Nope, not at all. Considering that the project is a set of packages, it is *way* easier to just distribute it using pypi. I'm in the process of removing the docs on the main site, so yeah, it's misleading. :( http://pypi.python.org/pypi?:action=display&name=pg_proboscis&version=0.9 Hrm, it's doesn't appear to have a way to list packages by submitter, but you can just search for 'pg', and you'll see my packages start with 'pg_'. I recommend using easy_install. See one of my responses to myself about problems with the ssl package. (Which I might as well not list as a dependency, but I planned to implement it soon, so there it is. Trying to contact the ssl package maintainer so that it can become easy_install friendly.... ;) Oh, if you don't have "easy_install", you'll probably need to install setuptools. Well, you'll need it regardless of using easy_install as it uses setuptools. (ugh, I only rely it for dependency resolution.. hrm..) > 2) What is the best way to learn about the new features? I hate to say so, but poking around in the console and using help(). :( Also, the tests in postgresql.protocol.greentrunk.test goes over a few of the features. (d/l source or unzip the egg) However, it's not really so bad as you can just connect using pb_python: pb_python -h localhost -U user -d dbname This will give you a Python console that has an additional built-in named 'GTX'. This is an established connection object. Running dir() and help() on the objects that you create should be somewhat informative. Some things to look at: Connections "autocommit" by default now. I don't believe it did this before. Queries ultimately return standard Python objects instead of the rather nasty "Postgres type instances" that typical used to keep. Arrays are handled with postgresql.types.array. This implements arrays similar to Postgres as opposed to Python; accessing out of bounds indexes returns None. (Not sure if this is the right way to go just yet, but using nested tuples or lists is *not* the way to go) DDL statements return a ResultHandle object. To get the count or the command of the statement, you have use the count and command methods on the object: rh = GTX.Query("INSERT INTO foo VALUES ($1)")(2) rh.count() rh.command() "Transact" should be gone; the 'Transaction' object on the connection manages the transaction state of the connection. It includes with-statement support and configurable isolation. The 'Settings' object replaces the broken 'Parameter' object. I changed the name as 'Settings' lends to "SET". Standard dictionary interface to the SHOW/SET command. COPY is fantastically simplified: for x in GTX.Query("COPY foo TO STDOUT"): sys.stdout.write(x) GTX.Query("COPY foo FROM STDIN")(sys.stdin) It uses simple iterators, expecting or giving a single COPY line. Additionally, the ResultHandle object has standard file-object interfaces for dealing with copies in bulk. `rh.write([line1, line2, ..., linen,])` or `rh.read(10)` for COPY to standard out. From pgsql at jwp.name Wed Jan 9 23:48:23 2008 From: pgsql at jwp.name (James William Pye) Date: Wed, 9 Jan 2008 16:48:23 -0700 Subject: pg_proboscis 0.9 release In-Reply-To: <010920082206.13805.478545710001BB94000035ED22069984999D0A900E04050E@comcast.net> References: <010920082206.13805.478545710001BB94000035ED22069984999D0A900E04050E@comcast.net> Message-ID: On Jan 9, 2008, at 3:06 PM, Adrian Klaver wrote > I ran into a problem trying to install the ssl module. I downloaded > the tarball and did > python setup.py install from the directory. It seems to want to go > the egg route and download > the module. Here is the error print out. ugh. Well, I went ahead and removed it as a dependency in 0.9.1. Try easy_install pg_proboscis, again. The ssl module seems to be something created as a back-port of the ssl module in 2.6. Too bad it doesn't just work with easy_install :( From pgsql at jwp.name Thu Jan 10 22:53:36 2008 From: pgsql at jwp.name (James William Pye) Date: Thu, 10 Jan 2008 15:53:36 -0700 Subject: pg_pqueue 0.9.2 released Message-ID: <20080110225336.GA9364@lit.jwp.name> This fixes a build issue regarding Py_ssize_t(missing lenfunc) on pre-2.5 Pythons. Alternatively, one could choose to only build Python modules and use the pbuffer.py. (a bit more painful, but doable) From pgsql at jwp.name Fri Jan 11 04:00:22 2008 From: pgsql at jwp.name (James William Pye) Date: Thu, 10 Jan 2008 21:00:22 -0700 Subject: pg_proboscis and pg_typical 0.9.2 released Message-ID: <20080111040022.GA1558@lit.jwp.name> For typical, this fixes issues with pre-2.5 versions of Python. The code uses a struct.Struct instance when available, otherwise fallback to struct.pack and struct.unpack. The closures were returning None, always. ;P For proboscis, the Query.load()(<<) method was not limiting the set of data to be sent as it should have been. Rather, it sent all the data supplied by the given iterator; in addition to be very expensive memory-wise, it also caused buffer exhaustion on most systems(ie, "frozen" socket). Some good fixes. If you tried using it with 2.4, chances are that this will fix the main problem that you experienced! :) To upgrade: easy_install -U pg_typical easy_install -U pg_proboscis From pgsql at jwp.name Mon Jan 14 01:15:41 2008 From: pgsql at jwp.name (James William Pye) Date: Sun, 13 Jan 2008 18:15:41 -0700 Subject: pg_proboscis 0.9.3 Message-ID: <20080114011541.GA16378@lit.jwp.name> pg_proboscis 0.9.3 released. This fixes more problems with the ``load()`` method on query objects. Load was problematic because it's the only operation that makes use of FlushMessages; these messages do not cause the backend to synchronize with the client, so in cases of errors in ``load()``, the client must explicitly issue an "additional" synchronize message. load was not doing this, so failures inside load would cause a connection to become unresponsive until a synchronize message was finally sent--likely with the ultimate result of an unexpected exception. Or in cases where non-extended protocol messages were sent, indefinitely unresponsive due to the protocol transaction capitalizing the connection state. From pgsql at jwp.name Mon Jan 14 04:41:36 2008 From: pgsql at jwp.name (James William Pye) Date: Sun, 13 Jan 2008 21:41:36 -0700 Subject: Next Versions Message-ID: <20080114044136.GA75918@lit.jwp.name> What's in Store for the next Versions ------------------------------------- pg_pqueue 1.0: Full protocol validation. Currently, some protocol violations may shine through mis-labeled. pg_proboscis 0.10: The APIs will change slightly in version 1.0, so 0.10 will be the bridge. A protocol transaction queue will be provided for additional performance enhancements especially in the area of garbage collection and transaction management. The API change is due for shortening names, and ridding of capitals(gtx.query instead of GTX.Query, gtx.xact instead of GTX.Transaction). pg_greentrunk 1.0: Expanded test suite and connection API documentation via the ``connection`` module. Additionally, gtx_python commands will be initialized with more builtins extracted from the connection object(query, cursor, xact, ). pg_boss 1.0: A better HBA interface is desperately needed. However, doing this will require the module have a real understanding of HBA files as oppposed to a loose grasp of the basic syntax. Addition of ``pg_dotconf``, and ``pg_hba`` scripts. pg_foundation 1.0: Addition of the postgresql.strings module. This module will provide some basic parsing routines for common storage mechanisms; ie, comma separated lists of identifiers, lists of literals. Expanded postgresql.exceptions. pg_teop ?.?: I'm taking a break on the PL until I get the driver solidified. Once that's done, I'll be focusing on the PL again. The things left to be done in the PL are better testing, bug fixes, simplified build process, and support for newer versions of Postgres. 8.2 is *still* in CVS. :( From noreply at pgfoundry.org Tue Jan 15 02:12:17 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Tue, 15 Jan 2008 02:12:17 +0000 (UTC) Subject: [ python-Bugs-1010237 ] Implement __nonzero__ in tracenull.GreenTrunk_Connection Message-ID: <20080115021217.E33FF17AC901@pgfoundry.org> Bugs item #1010237, was opened at 2008-01-14 19:12 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010237&group_id=1000094 Category: FE/Proboscis Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Implement __nonzero__ in tracenull.GreenTrunk_Connection Initial Comment: Add a nonzero method that allows a user to identify a connection that can process a query without causing a known exception. So self.state not in ('E', 'LOST', None) and not self.closed. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010237&group_id=1000094 From pgsql at jwp.name Wed Jan 16 03:38:31 2008 From: pgsql at jwp.name (James William Pye) Date: Tue, 15 Jan 2008 20:38:31 -0700 Subject: pg_proboscis 0.9.4 Message-ID: <20080116033831.GA83241@lit.jwp.name> Yes, another quick one. =) This fixes problems with dropped connections and provides a consistent exception when such situations occur. The problem was that the driver simply did not detect unexpected EOFs. It would indefinitely read from the socket; sigh. Now, it raises the pg.exc.ConnectionFailureError exception in such cases, and in cases of a broken pipe(errno.EPIPE). The dbapi2 module was simply broken. It's fixed now. Well, to the extent that Stuart Bishop's anal compliance tests don't fail. While GreenTrunk is the target of pg_proboscis, a full featured DB-API 2.0 implementation is important. Feel free to bring up any issues that you have with the DB-API 2.0 module. (postgresql.interface.proboscis.dbapi2) easy_install -u pg_proboscis -jwp From noreply at pgfoundry.org Wed Jan 16 03:47:27 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Wed, 16 Jan 2008 03:47:27 +0000 (UTC) Subject: [ python-Bugs-1010238 ] SSL support Message-ID: <20080116034728.28A6017AD07E@pgfoundry.org> Bugs item #1010238, was opened at 2008-01-15 20:47 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010238&group_id=1000094 Category: FE/Proboscis Group: To do Status: Open Resolution: None Priority: 4 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: SSL support Initial Comment: The logic is there, but it does not appear to work very well. Fix the sslmode support, and implement usage of the ssl module that appears in 2.6. PostgreSQL 8.3 has support for checking certificates; be sure to add this as well; the ssl module does have the necessary facilities to accomplish this. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010238&group_id=1000094 From noreply at pgfoundry.org Wed Jan 16 03:53:01 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Wed, 16 Jan 2008 03:53:01 +0000 (UTC) Subject: [ python-Bugs-1010239 ] Add strings module Message-ID: <20080116035301.99EF417AD07E@pgfoundry.org> Bugs item #1010239, was opened at 2008-01-15 20:52 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094 Category: lo/foundation Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add strings module Initial Comment: Add a strings module to foundation. This module will provide split routines for working with SQL identifiers and SQL literals. Join routines for common SQL serializations. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094 From noreply at pgfoundry.org Wed Jan 16 04:05:02 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Wed, 16 Jan 2008 04:05:02 +0000 (UTC) Subject: [ python-Bugs-1010240 ] Add connection documentation/specification module Message-ID: <20080116040502.78B1A17ACF2C@pgfoundry.org> Bugs item #1010240, was opened at 2008-01-15 21:05 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010240&group_id=1000094 Category: ip/greentrunk Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add connection documentation/specification module Initial Comment: Add the `connection` module to ip. This module will provide the specification for the GreenTrunk connection interface. The attributes in the module represent the attributes on the connection. Normally, the module attributes will be classes so as to provide a means to describe each element's interface. eg, postgresql/protocol/greentrunk/connection.py: class query(object): """ create a prepared statement using the given SQL source """ class cursor(object): """ create an interface to an already existing cursor """ class xact(object): """ manage the connection's transaction state """ ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010240&group_id=1000094 From noreply at pgfoundry.org Wed Jan 16 04:11:05 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Wed, 16 Jan 2008 04:11:05 +0000 (UTC) Subject: [ python-Bugs-1010241 ] Finish the hba module Message-ID: <20080116041105.3068D17ACF2C@pgfoundry.org> Bugs item #1010241, was opened at 2008-01-15 21:11 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010241&group_id=1000094 Category: ctl/boss Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Finish the hba module Initial Comment: Provide a interface to HBA files that allows the mere specification of whether someone should be allowed or disallowed and process the file as needed. This will require the module understand the HBA file as opposed to a loose grasp of the syntax. allow(type, user, database, host, ...) give permission disallow(type, user, database, host, ...) revoke permission reject() explicitly reject allowed() check if someone is allowed ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010241&group_id=1000094 From noreply at pgfoundry.org Wed Jan 16 04:12:16 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Wed, 16 Jan 2008 04:12:16 +0000 (UTC) Subject: [ python-Bugs-1010242 ] Add pg_hba and pg_dotconf commands Message-ID: <20080116041216.8CC0D17ACF2C@pgfoundry.org> Bugs item #1010242, was opened at 2008-01-15 21:12 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010242&group_id=1000094 Category: ctl/boss Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add pg_hba and pg_dotconf commands Initial Comment: For the most part, these will be scripts that point at: pg_hba -> postgresql.backend.boss.hba pg_dotconf -> postgresql.backend.boss.config ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010242&group_id=1000094 From noreply at pgfoundry.org Thu Jan 17 06:13:12 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Thu, 17 Jan 2008 06:13:12 +0000 (UTC) Subject: [ python-Bugs-1000464 ] New test infrastructure Message-ID: <20080117061312.6AEBD17AD0D9@pgfoundry.org> Bugs item #1000464, was opened at 2005-12-03 22:41 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000464&group_id=1000094 Category: be/teop Group: To do Status: Open Resolution: None Priority: 5 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: New test infrastructure Initial Comment: The current test system is far too limited for the needs of BE/TEOP. The system needs to be able to deal with multiple PostgreSQL and Python installations in a much more elegant fashion. Currently, the system rigidly works merely with multiple PostgreSQL versions but use with a given version is exclusive at a given run. This is simply annoying and needs automation. The proposed system will have the following features: - Configuration against multiple versions of PostgreSQL and Python. - A Postmaster controller to better handle and recover from fatal failures(?). - Unit test style testing framework to ease conditional testing of features. - Internal unit testing link-up to ease testing features from the inside(+/-). - Proboscis based. =) - Interactive prompt and automated runs (+/-) Requirements to meet these demands: - Simplified initdb interface (put in layout's utilities) - Postmaster controller (perhaps the most demanding) (maybe in layout as well) - Custom unittest framework subtypes to facilitate database connections. - Some sort of external reporting of internal testing. - Core dump management(?) [Would be nice to get tracebacks] - Green Trunk tests(?) This is planned for 0.4. Such a system with the appropriate tests would likely be the bane of all bugs. muahhah-muahaha-muahahahahahhaha ---------------------------------------------------------------------- >Comment By: James Pye (jwp) Date: 2008-01-16 23:13 Message: This new test framework will encompass all projects. pkg will implement it the framework for it using boss and tin. ---------------------------------------------------------------------- Comment By: James Pye (jwp) Date: 2006-08-06 18:20 Message: Many of these have been recently addressed with the ctl, tin, and console(GTX) projects. Many new tests will make their way into the IP project as a way to test exposed Green Trunk interfaces. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000464&group_id=1000094 From noreply at pgfoundry.org Thu Jan 17 06:16:07 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Thu, 17 Jan 2008 06:16:07 +0000 (UTC) Subject: [ python-Bugs-1010243 ] Add fetch module Message-ID: <20080117061608.0B6BC17AD0D9@pgfoundry.org> Bugs item #1010243, was opened at 2008-01-16 23:16 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010243&group_id=1000094 Category: ctl/boss Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add fetch module Initial Comment: Implement a module to provide a means for getting the source to an arbitrary version of PostgreSQL. python -m postgresql.backend.boss.fetch -v 8.0.x This will be used for test automation and convenience. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010243&group_id=1000094 From noreply at pgfoundry.org Thu Jan 17 06:22:41 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Thu, 17 Jan 2008 06:22:41 +0000 (UTC) Subject: [ python-Bugs-1010244 ] Add build module Message-ID: <20080117062241.9253617AD0D9@pgfoundry.org> Bugs item #1010244, was opened at 2008-01-16 23:22 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010244&group_id=1000094 Category: ctl/boss Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add build module Initial Comment: Add a module to build a source distribution of PostgreSQL. This will be used for test automation. Build a given version of Postgres with a combination of configuration parameters. Useful for ev Platform difficulties? Should this actually be in boss? ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010244&group_id=1000094 From noreply at pgfoundry.org Fri Jan 18 04:36:59 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Fri, 18 Jan 2008 04:36:59 +0000 (UTC) Subject: [ python-Bugs-1010245 ] Add DSN parser to client.utility Message-ID: <20080118043659.99C7A17AD0A8@pgfoundry.org> Bugs item #1010245, was opened at 2008-01-17 21:36 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010245&group_id=1000094 Category: lo/foundation Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add DSN parser to client.utility Initial Comment: Similar to the iri module, make a DSN parser. In fact, try to yield a consistent API with what's in iri.py. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010245&group_id=1000094 From noreply at pgfoundry.org Fri Jan 18 22:47:47 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Fri, 18 Jan 2008 22:47:47 +0000 (UTC) Subject: [ python-Bugs-1010246 ] Prepared transaction interfaces Message-ID: <20080118224747.CF81D17AD07E@pgfoundry.org> Bugs item #1010246, was opened at 2008-01-18 15:47 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010246&group_id=1000094 Category: fe/proboscis Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Prepared transaction interfaces Initial Comment: Two interfaces need to be described. Initial preparation and final commit. Initial prepare can be handled by the regular transaction manager: with gtx.xact('gid'): ... In which case, the usual COMMIT is replaced with a PREPARE TRANSACTION 'gid'. Additionally, an interface needs to be developed for committing a set of transactions. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010246&group_id=1000094 From pgsql at jwp.name Sat Jan 19 18:28:15 2008 From: pgsql at jwp.name (James William Pye) Date: Sat, 19 Jan 2008 11:28:15 -0700 Subject: Prepared Transactions Message-ID: <20080119182815.GA7436@lit.jwp.name> Per a recent thread that I saw on DB-SIG, I realized that I had completely forgotten about prepared transactions; certainly this is something that needs to be covered soon, so I started to think of what should be done with the current transaction manager to accomplish some aspects of this.. ISTM that there are two distinct components that must be managed separately--surely obvious, the initial prepare and the final commit or rollback. The initial prepare can and should be handled using the existing manager: with gtx.xact('xid'): ... or: gtx.xact('xid') with gtx.xact: ... That is, if a transaction is configured as being "identified", the transaction manager will issue a "PREPARE TRANSACTION '%(gid)s'" instead of the standard commit. Very simple and very handy. The one problem with this is that alone it requires some redundancy for simple 2PC applications: with nested( gtx1.xact('xid'), gtx2.xact('xid'), ): ... But notably, there is a potential need for solitude, so I think that having this as a starting point for prepared transactions *is* good. That leaves managing final commits and rollbacks, so I think simply adding two methods to gtx.xact would suffice for basic interface: class xact(object): ... def commit_prepared(self, gid): ... def rollback_prepared(self, gid): ... ... Arguably, the connection is just as good of a place for these methods to exist. However, the connection's transaction manager seems apt. And finally, other than something that provides with statement support for a set of transactions, I'm not sure what else should be done: class xactset(object): def __init__(self, gid, *cset): self.gid = gid self.cset = cset def __context__(self): return self def __enter__(self): for c in cset: c.xact(self.gid) def __exit__(self, typ, ob, tb): if typ is None: for c in cset: c.xact.commit_prepared(self.gid) else: for c in cset: c.xact.rollback_prepared(self.gid) with xactset( 'gid', gtx1, gtx2, ..., gtxn ): ... However, I'm really unsure where something like this should exist. =\ I guess the greentrunk package would be appropriate enough, but that doesn't seem particularly convenient: >>> from postgresql.protocol.greentrunk.transactions import xactset These are features that will make it into 1.0. Thoughts? From noreply at pgfoundry.org Fri Jan 25 03:16:24 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Fri, 25 Jan 2008 03:16:24 +0000 (UTC) Subject: [ python-Bugs-1010250 ] Correct ctl freezes Message-ID: <20080125031624.6C91917AD0A8@pgfoundry.org> Bugs item #1010250, was opened at 2008-01-24 20:16 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010250&group_id=1000094 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: Nobody (None) Summary: Correct ctl freezes Initial Comment: Sometimes pg_ctl and initdb will freeze. This is likely due to some blocked writes for some reason. Further investigation is needed. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010250&group_id=1000094 From pgsql at jwp.name Sat Jan 26 18:46:55 2008 From: pgsql at jwp.name (James William Pye) Date: Sat, 26 Jan 2008 11:46:55 -0700 Subject: Connection API Message-ID: <20080126184655.GA1263@lit.jwp.name> I've changed how I'm defining the connection APIs. Before I tried to formalize it in a DocBook document. However, this has proven tedious, and somewhat inhibiting for more rapid development. So, I added a module to pg_greentrunk which defines classes and functions that represent the attributes of a connection. Each class has doc-strings describing the interface of the attribute and whether it's a property or constructor. pg_greentrunk also includes an aptly named script, pg_greentrunk, that simply runs help() on the module to show the APIs and their documentation. Currently, this is in CVS, so if you want to look at what's there so far, you'll have to checkout head of the 'ip' module. Attached is the output of that script. -------------- next part -------------- Help on module postgresql.protocol.greentrunk.connection in postgresql.protocol.greentrunk: NAME postgresql.protocol.greentrunk.connection FILE /src/org/pgfoundry/python/pkg/prefix/python1/lib/python/pg_greentrunk-1.0dev-py2.5.egg/postgresql/protocol/greentrunk/connection.py DESCRIPTION pg_greentrunk is a Python API to the PostgreSQL RDBMS. It is designed to take full advantage of the database elements provided by PostgreSQL to provide the Python programmer with substantial convenience. This module is used to define the GreenTrunk API. The attributes of the module represent the attributes on a connection object. Most of the time, when a class is defined, it represents the interface of the object that's created by calling the method or callable attribute on the connection. Implementations are only required to take the parameters described by the ``__init__`` method of the class and return an object that provides the interface described by the class. Connection objects aren't required to be a part in any special class hierarchy. Merely, the Python protocol described here must be supported. For instance, a module object could be a connection to the database. CLASSES __builtin__.object cursor path proc query cquery statement settings type version_info xact class cquery(query) | A cquery object is a query object whose query is cached using using a finite | map of query strings to query objects. Once instantiated, the query object | is held until the connection is closed. | | Usually, ``query`` is the more appropriate attribute to make use of as it | allows program to leverage garbage collection to dispose of unused statements. | | Method resolution order: | cquery | query | __builtin__.object | | Methods inherited from query: | | __call__(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows, a cursor object should be returned, otherwise a | resulthandle object. | | Usage: | >>> con.query("SELECT table_name FROM information_schema.tables WHERE | table_schema = $1")('public') | | | __del__(self) | Close the prepared statement on the server as the only reference to its | existence is gone. | | __init__(self, sql, *default_args) | Create an object referencing a prepared statement that provides an | interface to the prepared statement. | | Given a single SQL statement, and optional default arguments, create the | prepared statement. The object returned is the interface to the | prepared statement. | | __invert__(self) | Shorthand for a call to the first() method without any arguments. | Useful for resolving static queries. | | Usage: | >>> ~con.query("INSERT INTO ttable VALUES ('value')") | 1 | >>> ~con.query("SELECT 'somestring'") | 'somestring' | | close(self) | Close the prepraed statement releasing resources associated with it. | | first(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows with multiple columns, return the first row. If the | query returns rows with a single column, return the first column in the | first row. | | Usage: | >>> con.query("SELECT * FROM ttable WHERE key = $1").first("somekey") | ('somekey', 'somevalue') | | prepare(self) | Prepare the already instantiated query for use. This method would only be | used if the query closed. | | ---------------------------------------------------------------------- | Data descriptors inherited from query: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class cursor(__builtin__.object) | A cursor object is an interface to a sequence of tuples(rows). A result set. | Cursors publish a file like interface for reading tuples from the database. | | Methods defined here: | | __getitem__(self, idx) | Get the rows at the given absolute position. | | __init__(self, portal_id) | Create a reference object to an already created cursor. In this case, | losing the cursor object does *not* result in the cursor being closed. | Explicitly referenced cursors must be explicitly closed for their | resources to be released. This is in contrast to cursor objects created | from query invocation, which will closed after __del__ is called on the | object. | | __next__(self) | Get the next item tuple in the cursor. | | close(self) | Close the cursor to release its resources. | | next = __next__(self) | | read(self, quantity=-1) | Read the specified number of tuples and return them in a list. | This advances the cursor's position. | | scroll(self, rows) | Set the cursor's position relative to the current position. | Negative numbers can be used to scroll backwards. | | seek(self, offset, whence=0) | Set the cursor's position to the given offset with respect to the | whence parameter. | 0 - being absolute. | 1 - being relative. | 2 - begin absolute from end. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class path(__builtin__.object) | path is a property providing access to a structured version of search_path. | | >>> con.path | ['public', 'pg_catalog'] | | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class proc(__builtin__.object) | A proc object is an interface to a stored procedure. | | Methods defined here: | | __call__(self, *args, **kw) | Execute the procedure with the given arguments. If keyword arguments are | passed they must be mapped to the argument whose name matches the key. If | any positional arguments are given, they must fill in any gaps created by | the filled keyword arguments. If too few or too many arguments are given, | a TypeError must be raised. If a keyword argument is passed where the | procudure does not have a corresponding argument name, then, likewise, a | TypeError must be raised. | | __init__(self, procid) | Create a reference to a stored procedure on the database. The given | identifier can be either an Oid or a valid regprocedure string pointing at | the desired function. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class query(__builtin__.object) | A query object is an interface to a prepared statement. | | Methods defined here: | | __call__(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows, a cursor object should be returned, otherwise a | resulthandle object. | | Usage: | >>> con.query("SELECT table_name FROM information_schema.tables WHERE | table_schema = $1")('public') | | | __del__(self) | Close the prepared statement on the server as the only reference to its | existence is gone. | | __init__(self, sql, *default_args) | Create an object referencing a prepared statement that provides an | interface to the prepared statement. | | Given a single SQL statement, and optional default arguments, create the | prepared statement. The object returned is the interface to the | prepared statement. | | __invert__(self) | Shorthand for a call to the first() method without any arguments. | Useful for resolving static queries. | | Usage: | >>> ~con.query("INSERT INTO ttable VALUES ('value')") | 1 | >>> ~con.query("SELECT 'somestring'") | 'somestring' | | close(self) | Close the prepraed statement releasing resources associated with it. | | first(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows with multiple columns, return the first row. If the | query returns rows with a single column, return the first column in the | first row. | | Usage: | >>> con.query("SELECT * FROM ttable WHERE key = $1").first("somekey") | ('somekey', 'somevalue') | | prepare(self) | Prepare the already instantiated query for use. This method would only be | used if the query closed. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class settings(__builtin__.object) | A mapping interface to the session's settings. This dictionary-like object | provides a direct interface to SHOW/SET commands. Identifiers and values need | not be quoted specially as the implementation must do that work for the user. | | Methods defined here: | | __getitem__(self, key) | Return the setting corresponding to the given key. The result should be | consistent with what the SHOW command returns. If the key does not exist, | raise a KeyError. | | __setitem__(self, key, value) | Set the setting with the given key to the given value. The action should | be consisten with the effect of the SET command. | | get(self, key, default=None) | Get the setting with the corresponding key. If the setting does not exist, | return the default(defaults to None). | | items(self) | Return an iterator to all of the setting value pairs. | | iteritems(self) | Return an iterator to all of the setting value pairs. | This method is provided for compatibility with dictionary objects. | | iterkeys(self) | Return an iterator to all of the settings' keys. | This method is provided for compatibility with dictionary objects. | | itervalues(self) | Return an iterator to all of the settings' values. | This method is provided for compatibility with dictionary objects. | | keys(self) | Return an iterator to all of the settings' keys. | | update(self, mapping) | For each key-value pair, incur the effect of the __setitem__ method. | | values(self) | Return an iterator to all of the settings' values. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class statement(query) | A query object that was prepared on the server side. The distinction between | this and a regular query is that it must be explicitly closed if it is no | longer desired, and it is instantiated using the statement identifier as | opposed to the SQL statement itself. | | Method resolution order: | statement | query | __builtin__.object | | Methods defined here: | | __del__(self) | Nothing happens if a server prepared statement reference is lost. | | __init__(self, statement_id) | Create a ``query`` object from the given statement identifier. | | ---------------------------------------------------------------------- | Methods inherited from query: | | __call__(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows, a cursor object should be returned, otherwise a | resulthandle object. | | Usage: | >>> con.query("SELECT table_name FROM information_schema.tables WHERE | table_schema = $1")('public') | | | __invert__(self) | Shorthand for a call to the first() method without any arguments. | Useful for resolving static queries. | | Usage: | >>> ~con.query("INSERT INTO ttable VALUES ('value')") | 1 | >>> ~con.query("SELECT 'somestring'") | 'somestring' | | close(self) | Close the prepraed statement releasing resources associated with it. | | first(self, *args) | Execute the prepared statement with the given arguments as parameters. If | the query returns rows with multiple columns, return the first row. If the | query returns rows with a single column, return the first column in the | first row. | | Usage: | >>> con.query("SELECT * FROM ttable WHERE key = $1").first("somekey") | ('somekey', 'somevalue') | | prepare(self) | Prepare the already instantiated query for use. This method would only be | used if the query closed. | | ---------------------------------------------------------------------- | Data descriptors inherited from query: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class type(__builtin__.object) | type is a property providing the name of the database type. 'PostgreSQL' | would be the usual case. However, other "kinds" of Postgres exist in the | wild. Greenplum for example. | | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class version_info(__builtin__.object) | version_info is a version tuple of the database software similar Python's | sys.version_info. It should be an instance of | ``postgresql.utility.version.one``. | | >>> con.version_info | (8, 1, 3, '', 0) | | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) class xact(__builtin__.object) | A xact object is the connection's transaction manager. It is already | instantiated for every connection. It keeps the state of the transaction and | provides methods for managing the state thereof. | | Normal usage would merely entail the use of with-statement: | | with con.xact: | ... | | If no prior starts or blocks have been opened, that results in a transaction | block being started. | | Methods defined here: | | __call__(self, gid=None, isolation=None, readonly=None) | Configure the transaction block using the given arguments. | | The ``isolation`` keyword must be a character string stating the ISOLATION | LEVEL of the transaction block. | | The ``readonly`` keyword must be a boolean signifying whether the | transaction should be started in read-only mode. | | The ``gid`` keyword and first positional argument states the transaction | identifier to be used for a prepared transaction. When this option is not | None, the transaction will not issue a COMMIT on an invocation to the | ``commit`` method. Rather, a PREPARE TRANSACTION statement will be issued | with the ``gid`` parameter. | | __context__(self) | Return self | | __enter__ = start(self) | | __exit__(self, typ, obj, tb) | Commit the transaction, or abort if the given exception is not None. If | the transaction level is greater than one, then the savepoint | corresponding to the current level will be released or rolled back in | cases of an exception. | | If an exception was raised, then the return value must indicate the need | to further raise the exception, unless the exception is an | AbortTransaction. In which case, the transaction will be rolled back | accordingly, but the exception will not be raised. | | abort = rollback(self) | | begin = start(self) | | checkpoint(self) | Commit and start a transaction block or savepoint. Not to be confused with | the effect of the CHECKPOINT command. | | commit(self) | Commit the transaction block, release a savepoint, or prepare the | transaction for commit. If the number of running transactions is greater | than one, then the corresponding savepoint is released. If no savepoints | are set and the transaction is configured with a 'gid', then the | transaction is prepared instead of committed, otherwise the transaction is | simply committed. | | restart(self) | Abort and start the transaction or savepoint. | | rollback(self) | Abort the current transaction or rollback to the last started savepoint. | ``rollback`` and ``abort`` are synonyms. | | start(self) | Start a transaction block. If a transaction block has already been | started, set a savepoint. | ``start``, ``begin``, and ``__enter__`` are synonyms. | | ---------------------------------------------------------------------- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) FUNCTIONS execute(sql) Execute an arbitrary block of SQL. Always returns None and raises an exception on error. DATA __loader__ = Bugs item #1010239, was opened at 2008-01-15 20:52 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094 Category: lo/foundation Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add strings module Initial Comment: Add a strings module to foundation. This module will provide split routines for working with SQL identifiers and SQL literals. Join routines for common SQL serializations. ---------------------------------------------------------------------- >Comment By: James Pye (jwp) Date: 2008-01-27 14:46 Message: Some simple functions are finished on this. split_qname works and has tests written for it. The primary split function provides a simple way to segregate quoted sections from non-quoted sections: split("select 'foo'") -> ['select ', ("'", 'foo'), ''] With the trailing empty string indicating that the quoted section was terminated properly. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094 From noreply at pgfoundry.org Sun Jan 27 21:49:54 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Sun, 27 Jan 2008 21:49:54 +0000 (UTC) Subject: [ python-Bugs-1010253 ] Fix DB-API parameter substitution Message-ID: <20080127214954.3042117AD0D3@pgfoundry.org> Bugs item #1010253, was opened at 2008-01-27 14:49 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010253&group_id=1000094 Category: fe/proboscis Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Fix DB-API parameter substitution Initial Comment: Currently the DB-API layer stupidly substitutes '?' for $n. This can cause issues if a question-mark is placed in a quoted section. Additionally, switch the paramstyle to named parameters to sync up with psycopg2. This depends on the strings module being added to pg_foundation. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010253&group_id=1000094 From noreply at pgfoundry.org Sun Jan 27 22:45:23 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Sun, 27 Jan 2008 22:45:23 +0000 (UTC) Subject: [ python-Bugs-1010240 ] Add connection documentation/specification module Message-ID: <20080127224523.12EAD17AD0D3@pgfoundry.org> Bugs item #1010240, was opened at 2008-01-15 21:05 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010240&group_id=1000094 Category: ip/greentrunk Group: None Status: Open Resolution: None Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add connection documentation/specification module Initial Comment: Add the `connection` module to ip. This module will provide the specification for the GreenTrunk connection interface. The attributes in the module represent the attributes on the connection. Normally, the module attributes will be classes so as to provide a means to describe each element's interface. eg, postgresql/protocol/greentrunk/connection.py: class query(object): """ create a prepared statement using the given SQL source """ class cursor(object): """ create an interface to an already existing cursor """ class xact(object): """ manage the connection's transaction state """ ---------------------------------------------------------------------- >Comment By: James Pye (jwp) Date: 2008-01-27 15:45 Message: This is in HEAD now. It certainly needs some editorializing, but luxuries and such may prohibit. This documents just about every feature supported by proboscis. A couple more looks and I'll mark this as done. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010240&group_id=1000094 From noreply at pgfoundry.org Mon Jan 28 02:44:13 2008 From: noreply at pgfoundry.org (noreply at pgfoundry.org) Date: Mon, 28 Jan 2008 02:44:13 +0000 (UTC) Subject: [ python-Bugs-1010239 ] Add strings module Message-ID: <20080128024413.4BC0617AD0E7@pgfoundry.org> Bugs item #1010239, was opened at 2008-01-15 20:52 You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094 Category: lo/foundation Group: None >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: James Pye (jwp) Assigned to: James Pye (jwp) Summary: Add strings module Initial Comment: Add a strings module to foundation. This module will provide split routines for working with SQL identifiers and SQL literals. Join routines for common SQL serializations. ---------------------------------------------------------------------- >Comment By: James Pye (jwp) Date: 2008-01-27 19:44 Message: Done and checked into head. ---------------------------------------------------------------------- Comment By: James Pye (jwp) Date: 2008-01-27 14:46 Message: Some simple functions are finished on this. split_qname works and has tests written for it. The primary split function provides a simple way to segregate quoted sections from non-quoted sections: split("select 'foo'") -> ['select ', ("'", 'foo'), ''] With the trailing empty string indicating that the quoted section was terminated properly. ---------------------------------------------------------------------- You can respond by visiting: http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1010239&group_id=1000094