From noreply at pgfoundry.org  Sun Dec  2 22:25:07 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sun,  2 Dec 2007 22:25:07 +0000 (UTC)
Subject: [ python-Bugs-1000657 ] Type I/O routine segregation
Message-ID: <20071202222508.49BE917AC888@pgfoundry.org>

Bugs item #1000657, was opened at 2006-05-31 22:11
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000657&group_id=1000094

Category: IP/Green Trunk
Group: To do
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Type I/O routine segregation

Initial Comment:
Currently, the type system interfaces primarily attempt to massage I/O methods into the actual type's class object. The problem with this is using it as the standard mechanism to address the serialization and parsing routines. It's not readily extensible, nor flexible; for typical, it requires monkey patching, and for TEOP's TSI, it is likely not doable.

More and more, I am beginning to think this is a job for Green Trunk to hash out. That is, based on a few given parameters, lookup a routine to serialize an object to the identified protocol. Perhaps routines to do this serialization should be extensible through custom modulizations; going through Python module interfaces would likely be overkill.

Perhaps some notes could be taken from how pickle and marshal are done as it's fantastically similar.

To clarify why binding serialization and parsing methods to a "Postgres Type" is a bad idea, the cases are simple: What encoding should that string be serialized to or parsed from? Are those 64-bit integer times/timestamps or float8? Is that oidarray a fixed oidarray or is an Array oid array? Of course, all these question are subsequent to: I have an object, how do I serialize it for this context?

These type protocols need some sort of negotiation for realizing the structure of the transmitted object. The current system is fairly inflexible and based on a poorly thought out scheme for managing and addressing the various I/O routines.

Additionally, some plans need to be laid out for Connector specific typing where a UDT object may be transmitted.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-02 15:25

Message:
The latest version of typical addresses this, but has nothing to do with greentrunk. Rather it takes a KISS approach that simply implements binary type I/O associated with the oid. strings types that are encoded are not handled as it depends on the connection's configuration. Python provides decoding routines, so connection objects will probably use those directly. Time is implemented twice, one for 64-bit integers and the other for doubles. Some abstraction is provided by making it into a tuple containing the seconds and microseconds.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000657&group_id=1000094

From noreply at pgfoundry.org  Sun Dec  2 22:26:37 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sun,  2 Dec 2007 22:26:37 +0000 (UTC)
Subject: [ python-Bugs-1000391 ] bit types need to be string subtypes
Message-ID: <20071202222637.6C08017AC888@pgfoundry.org>

Bugs item #1000391, was opened at 2005-09-25 00:25
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000391&group_id=1000094

Category: TYP/Typical
Group: To do
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: bit types need to be string subtypes

Initial Comment:
bit and varbit types need to be a string subtype to avoid the overhead involved with using regular tuples.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-02 15:26

Message:
postgresql.types has a bit and varbit type that is a str subtype.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000391&group_id=1000094

From noreply at pgfoundry.org  Sun Dec  2 22:36:35 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sun,  2 Dec 2007 22:36:35 +0000 (UTC)
Subject: [ python-Bugs-1000298 ] Windows support
Message-ID: <20071202223635.ABC9817AC888@pgfoundry.org>

Bugs item #1000298, was opened at 2005-04-28 01:02
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000298&group_id=1000094

Category: BE/TEOP
Group: To do
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: Nobody (None)
Summary: Windows support

Initial Comment:
I'm not even sure where to begin as I do not have a Windows box. There are various issues with the build script that will surely fail.

Primarily the stupidity of ldistutil's custom build_so command to make shared objects.

Also, the PL library uses elf's _init routine to initialize Python and import the necessary libraries. There is an attempt to provide a Window's version of that, but I have little confidence that it will work as it is.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-02 15:36

Message:
Migration to a build system using PGXS will likely fix this issue. I believe I have successfully gotten the Python extension to build, but never the Postgres extension.

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2005-06-26 00:47

Message:
Logged In: YES 
user_id=100779

After some review, I am not sure if ldistutils will be able to handle it easily; surely not elegantly. Both build_so and build_ext suffer from the same resulting problem, missing PostgreSQL symbols. I assume this is resolved by linking against -lpostgres, which, at first glance, appeared to be the in PG's bin directory, but failed to work. There is also some extra hackery that needs to take place somewhere in the configure function: The python lib needs to be rebuilt against mingw32.

Also, asprintf is missing from mingw32, so a workaround will be necessary(thinking PyString_FromFormat).

(Note: sources probably need to be compiled with -mdll)

All in all, ugh.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000298&group_id=1000094

From noreply at pgfoundry.org  Sun Dec  2 22:39:03 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sun,  2 Dec 2007 22:39:03 +0000 (UTC)
Subject: [ python-Bugs-1000390 ] Array typinput does not support multiple
	dimensions
Message-ID: <20071202223903.9DBA817AC888@pgfoundry.org>

Bugs item #1000390, was opened at 2005-09-25 00:20
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000390&group_id=1000094

Category: TYP/Typical
Group: To do
>Status: Closed
>Resolution: Out of Date
Priority: 4
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Array typinput does not support multiple dimensions

Initial Comment:
typinput needs to be made to keep track of the state of the dimension level so as to validate the consistency of the array, and to initially build the boundaries of the dimensions for instantiation. Currently, only single dimension arrays work.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-02 15:39

Message:
postgresql.types.array has support to unroll a nested array. It requires that the container types be explicitly stated, but it works just fine for the usual case.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000390&group_id=1000094

From noreply at pgfoundry.org  Wed Dec 12 06:54:19 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Wed, 12 Dec 2007 06:54:19 +0000 (UTC)
Subject: [ python-Bugs-1002784 ] Lazy Proboscis
Message-ID: <20071212065419.CEF3E17AD0B6@pgfoundry.org>

Bugs item #1002784, was opened at 2007-04-01 11:37
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1002784&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: Lazy Proboscis

Initial Comment:
Currently, just about every database action requires the client to wait for the response. This isn't always necessary from a client's standpoint. Rather, it's only necessary to get the response when the response is requested.

For instance, in the usual Prepare->Bind->Execute scenario, it is only until execution occurs that the user wants to see information. So why require the user  to suffer the cost of the latency involved in three round trips when only one is necessary?

The only time this is really desired is when the user wants to realize success for a given segment, so an interface allowing realization is necessary.

Currently, I think it best to make lazy mode the default.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-11 23:54

Message:
The version of Proboscis in the works creates an idea of "stepping" through a protocol transaction. This will give the implementation the ability to prime transactions so that when the user comes back to an object, it's already been prepared or bound, or whatnot. However, this is not lazy evaluation.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1002784&group_id=1000094

From noreply at pgfoundry.org  Wed Dec 12 23:00:56 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Wed, 12 Dec 2007 23:00:56 +0000 (UTC)
Subject: [ python-Bugs-1000392 ] Finish authentication handlers
Message-ID: <20071212230056.AFDE617AC896@pgfoundry.org>

Bugs item #1000392, was opened at 2005-09-25 01:55
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000392&group_id=1000094

Category: PQ/PQueue
Group: To do
Status: Open
Resolution: None
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Finish authentication handlers

Initial Comment:
MD5, Crypt and Password are supported, but krb4, krb5 and ident are not.

http://starship.python.net/crew/fdrake/manuals/krb5py/krb5py.html
http://www.huque.com/python/pykpass/

Priority to ident and krb5.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-12 16:00

Message:
move auth to proboscis and push off implementing anything that does not have a stable Python module.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000392&group_id=1000094

From noreply at pgfoundry.org  Wed Dec 12 23:01:58 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Wed, 12 Dec 2007 23:01:58 +0000 (UTC)
Subject: [ python-Bugs-1000344 ] Localization
Message-ID: <20071212230158.2F69C17AC896@pgfoundry.org>

Bugs item #1000344, was opened at 2005-06-29 18:31
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000344&group_id=1000094

Category: BE/TEOP
Group: To do
>Status: Closed
Resolution: None
Priority: 2
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Localization

Initial Comment:
Localization of error messsages is not done at all, nor is there an established infrastructure for localizing. I am not sure how this is done with distutils, so I fear it may require some hackery in that area(fear the distutils, fear it good).

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-12 16:01

Message:
let's get a stable release before thinking about things that aren't demanded.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000344&group_id=1000094

From noreply at pgfoundry.org  Wed Dec 12 23:03:07 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Wed, 12 Dec 2007 23:03:07 +0000 (UTC)
Subject: [ python-Bugs-1000392 ] Finish authentication handlers
Message-ID: <20071212230307.B3C8F17AC896@pgfoundry.org>

Bugs item #1000392, was opened at 2005-09-25 01:55
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000392&group_id=1000094

Category: PQ/PQueue
Group: To do
>Status: Closed
Resolution: None
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Finish authentication handlers

Initial Comment:
MD5, Crypt and Password are supported, but krb4, krb5 and ident are not.

http://starship.python.net/crew/fdrake/manuals/krb5py/krb5py.html
http://www.huque.com/python/pykpass/

Priority to ident and krb5.

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2007-12-12 16:00

Message:
move auth to proboscis and push off implementing anything that does not have a stable Python module.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000392&group_id=1000094

From noreply at pgfoundry.org  Wed Dec 12 23:19:06 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Wed, 12 Dec 2007 23:19:06 +0000 (UTC)
Subject: [ python-Bugs-1003258 ] Use PGXS to build the PL module
Message-ID: <20071212231906.96E2417AC896@pgfoundry.org>

Bugs item #1003258, was opened at 2007-04-18 20:59
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1003258&group_id=1000094

Category: BE/TEOP
Group: To do
Status: Open
Resolution: None
Priority: 4
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Use PGXS to build the PL module

Initial Comment:
For a while now, teop has used a distutils extension to compile the PL module. While this paved the road for doing builds on Windows, and any platform supported by distutils that can compile CPython, it is difficult to maintain. While it extends distutils, so it should be portable, but chances are it's going to require more effort to maintain it than a PGXS makefile.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-12 16:19

Message:
Considering consolidating the Python extension module with the Postgres extension to continue to simplify the build process and to make it not such an exotic PL.
(the cases to keep them separate are not useful enough to justify the extra work)

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1003258&group_id=1000094

From noreply at pgfoundry.org  Sat Dec 22 09:11:39 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sat, 22 Dec 2007 09:11:39 +0000 (UTC)
Subject: [ python-Bugs-1002784 ] Lazy Proboscis
Message-ID: <20071222091140.0F41A17AC8A1@pgfoundry.org>

Bugs item #1002784, was opened at 2007-04-01 11:37
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1002784&group_id=1000094

Category: FE/Proboscis
Group: To do
>Status: Closed
>Resolution: Accepted
Priority: 4
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Lazy Proboscis

Initial Comment:
Currently, just about every database action requires the client to wait for the response. This isn't always necessary from a client's standpoint. Rather, it's only necessary to get the response when the response is requested.

For instance, in the usual Prepare->Bind->Execute scenario, it is only until execution occurs that the user wants to see information. So why require the user  to suffer the cost of the latency involved in three round trips when only one is necessary?

The only time this is really desired is when the user wants to realize success for a given segment, so an interface allowing realization is necessary.

Currently, I think it best to make lazy mode the default.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-22 02:11

Message:
While uncommitted, this is complete.

----------------------------------------------------------------------

Comment By: James Pye (jwp)
Date: 2007-12-11 23:54

Message:
The version of Proboscis in the works creates an idea of "stepping" through a protocol transaction. This will give the implementation the ability to prime transactions so that when the user comes back to an object, it's already been prepared or bound, or whatnot. However, this is not lazy evaluation.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1002784&group_id=1000094

From noreply at pgfoundry.org  Sat Dec 22 09:13:52 2007
From: noreply at pgfoundry.org (noreply at pgfoundry.org)
Date: Sat, 22 Dec 2007 09:13:52 +0000 (UTC)
Subject: [ python-Bugs-1000296 ] Relation interface
Message-ID: <20071222091352.BC34617AC8A1@pgfoundry.org>

Bugs item #1000296, was opened at 2005-04-28 00:22
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000296&group_id=1000094

Category: BE/TEOP
Group: To do
>Status: Closed
>Resolution: Postponed
Priority: 3
Submitted By: James Pye (jwp)
Assigned to: James Pye (jwp)
Summary: Relation interface

Initial Comment:
Get Postgres.Relation to inherit from Postgres.Object, implement direct insertions, and simple sequential iterators. Later more complicated scans should implemented by returning a special iterator from a __call__ call.

pg_proc_rel = Postgres.Catalog.Relation('pg_proc')
index_scan_iter = pg_proc_rel(proname = 'afunc'): ...

Something like that. Going to need to find a creative way to handle other comparison operators.

----------------------------------------------------------------------

>Comment By: James Pye (jwp)
Date: 2007-12-22 02:13

Message:
Let's leave this as a future feature. It's hard enough to get what's working stabilized.

----------------------------------------------------------------------

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000296&group_id=1000094