A connection-to-connection COPY management object which provides efficient transmission of COPY data.

This object will use a mutable buffer in conjunction with a function that will identify the current COPY state. Multiple target connections will need to be supported. Exceptions thrown by this object's main method will need to be generalized into a exception identifying the target that caused the failure. This will be one component in order to allow the user to craft fault tolerance capabilities. The next component is the ability to dynamically remove a target from the copy manager. This will allow the COPY to continue after the fault was identified as an acceptable risk.

Currently, the identifiers of notice message parts are being translated into descriptive identifiers--this is covers all the parts currently emitted by PG, but will not cover future parts.

PQ Notice messages need to use the single character part identifier to key the dictionary. Then, at a higher level, it can then be translated into something more useful.

postgresql.api.Message instances will also need to carry the original Notice/Error message..

Implement a symbol definition extension that allows the binding to identify that the symbol's statement is a reference
to the statement that should be executed.

If the symbol's statement takes no parameters, the reference should be resolved at bind time; if the statement does
take parameters, the symbol's execution must be a two step process: resolve the reference using the given parameters,
and apply the remaining parameters to the dereferenced statement.

This will establish a dynamic query policy: SQL should be used to generate dynamic statements.

While it may be easier in Python with the appropriate abstractions, it's implementation would require more semantic
knowledge of the statement's structure(execute this python code in a special context here, here and there). By deferring
to SQL, it will likely encourage more portable SQL generation.

Name: statement references | symbol pointers | ?

Format: [name&]

Use the '&' to lend toward C's reference operator.
I would like to prepend the character, but I don't want interfere with grep'ing.

PostgreSQL's advisory locks offers users a handy tool.

Add a lock interface that is consistent with threading's Lock():

l = db.lock()
Creates a lock object with a generated identifier

il = db.lock('explicit_id')
Creates a lock object with an explicit identifier.
Will need to derive an numeric ID from the string.

From there, l and il must support the methods provided by Lock():

l.acquire([blocking = 1])
l.release()

Additionaly, CM interfaces:

with l:
...

Where l.enter is consistent with l.acquire(blocking = True).

Two options:

1. Use pg_ctl.
2. Implement/steal pg_kill (what pg_ctl uses for supporting windows.)

Part of the ultimate purpose of Cluster() is to provide a postgres daemon manager. Using pg_ctl tends to get in the
way of that: no access to the process result code, no access to any early failure messages on startup(?), and indirect
access to the PostgreSQL "ping" tool for waiting for startup.

Practical problems implementing pg_kill: What happens when core changes it?
Problems using pg_ctl: Difficulty providing quality interfaces(bad past experiences).

The way I see it:

pg_ctl = DBA tool. postgresql.cluster.Cluster = Python Programmer's tool.

This distinction leads me to think that re-implementing pg_kill will be the right solution.

Move the core option information in clientparameters into a resource/data module to be referenced by clientparameters.

Currently option information is built and stored using make_option. With python-dev's apparent direction of moving to argparse, this no longer appears to be an appropriate long term format.

(Might be wise to consider multi-lingual support for the descriptions..)

The gid argument enabled a 2pc transaction. When given a gid, the transaction object required that the prepare() method be used before committing on exit. This was intended to provide an abstraction, but use in any distributed transaction manager is likely to lead to more pain than it's worth. For v1.0, the gid documentation will simply be removed, and in 1.1, we'll probably throw a deprecation warning if it's a provided. Subsequent versions will just throw the TypeError as the feature will not exist.

Use ctypes/libffi to implement libpq's usage of PGGSSLIB.

This is a significant barrier for entry for applications that work with many users.

Chances are that this will be implemented as a separate project and then incorporated into the package tree.

8.3 added the ability to lookup connection parameters using LDAP with libpq.

https://www.postgresql.org/docs/8.3/static/libpq-ldap.html
https://python-ldap.sourceforge.net/

Symbols don't provide any metadata. While statements can provide much of this information, procedure references require
some specialization wrt the exposed description.

A full description is needed:

parameter types parameter names optional parameters (due to procedure defaults[8.4 feature]) result types result column names (if applicable; single column results may not have names) result transformation/finalized type (if any; column/mapping)

How should COPY be described? o_O

I'm thinking along the lines of:

Bs.pg_description, Bs.sql_description

Where each attribute can express type identifiers in a native form...

Statements and procedures are a bit more simple than symbols, so I'm not optimistic about being able to directly reflect
their metadata attributes.

postgresql.cluster has made a serious effort in order to automate the management of PostgreSQL clusters using Python.

The next step is to expose these interfaces so that users may manage their PG data directories using a web interface: Web APIs(JSON and XML-RPC?) and a JavaScript GUI application.

The Web API will need the following actions:
- Identify an Installation - Forget an Installation - Initialize a data directory - Remove a data directory - List data directories - Start a cluster - Stop a cluster - Restart a cluster - Reload a cluster - Permanently set a setting in a cluster - Get a setting in a cluster - Get all settings in a cluster - Write the HBA file - Read the HBA file - Create a Database - Drop a Database ... (database management? )= - Create Role - Drop Role ... (role management? )= - WAL directory relocation (other directories?) - Logging Configuration?

Other ideas: cluster configuration templates, configuration restoration(last known working config mgmt).

The GUI part may need to come later, but it would be nice to have something in the first round.

Currently, type I/O is undocumented and in need of some API refactoring.

Also, type I/O on statements and cursors need to be adjustable.

Difficulties involve cases where the I/O routine may need to depend on backend specific information like integer_datetimes.