这是 Proboscis[1] 的第一个发布公告，它是基于 PQueue 的 Green
Trunk 实现。它是用于 Python 的 PostgreSQL 驱动程序/接口。又一个？
嗯，可以说是，也可以说不是。Proboscis 不是基于 libpq 的，也不是主要
生成 DB-API 2.0 接口（0.2 版本可能包含针对 DB-API 2.0 用户的层）。
可以在这里[2]找到发布新闻。
此前端具有以下特性，排名不分先后：
* 纯 Python
* Green Trunk 接口
* 线程安全
* Windows 支持
* 基本 SSL 支持
* 支持 COPY TO/FROM
* 协议级别的预处理语句和游标（Portals）
* 基于需求的游标活动
* 查询和过程方法（请参阅 Green Trunk 文档）
* bytea 透明性（提示：使用参数时无需转义）
* Wire Tap（异步通知）
* 自动客户端编码/解码
在此处[3]下载。
纯 Python？它一定很慢，不是吗？嗯，首先，有一个可选的 C
扩展模块，可以在一个敏感区域提供优化，因此它不一定
是纯 Python。随着 1.0 版本的临近，其他敏感区域也可能会被
优化。
那么它有多慢或多快？以下是一些简单的测试：
（服务器和客户端在同一台机器上）
复制，
COPY FROM 摘要，
复制的元组数：50000
复制的字节数：2882981
持续时间：2.186987
每个元组的平均大小（字节）：57.000000
每秒平均 KB：1287.159045
每秒平均元组数：22862.505244
COPY TO 摘要，
复制的元组数：50000
持续时间：2.299819
每秒平均 KB：1224.009372
每秒平均元组数：21740.841414
（警告：如果没有 C 扩展模块，COPY TO 的 TPS 将减半）
查询，
INSERT 摘要，
插入的元组数：1000
总时间：1.903957
每秒平均元组数：525.221976
（注意：批量 INSERT 在 0.2 版本中可能会快 2-3 倍）
SELECT 摘要，
循环次数：51
读取的元组数：1000
循环时间：0.323199
读取元组的时间：0.322262
循环开销：0.000937
每秒平均元组数：3103.064739
（警告：如果没有 C 扩展模块，SELECT 将会损失 1000 TPS）
虽然这些速度不太可能在实践中出现，但它确实让
我们了解了该接口在处理简单数据时的能力。
要快速入门，请参阅“快速开始”页面的“前端”部分[4]。如需
进一步帮助，请注册并向邮件列表[5]提问。
列表[5]提问。
[1] http://python.projects.postgresql.org/project/fe.html
[2] http://pgfoundry.org/forum/forum.php?forum_id=522
[3] http://pgfoundry.org/frs/?group_id=1000094&release_id=315
[4] http://python.projects.postgresql.org/quick.html
[5] http://lists.pgfoundry.org/mailman/listinfo/python-general
此帖子已从 PostgreSQL 网站的先前版本迁移。对于迁移造成的任何格式问题，我们深表歉意。