[ python-Bugs-1000657 ] Type I/O routine segregation

[noreply at 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