Re: Confusion over Python drivers

From: James William Pye <lists(at)jwp(dot)name>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Confusion over Python drivers
Date: 2010-02-07 04:50:31
Message-ID: 75B8647D-13A8-49BB-A366-384FBFE2E120@jwp.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Feb 6, 2010, at 5:51 PM, Josh Berkus wrote:
>> Finally, I just don't see the existing (often PG specific) goals that I have in mind for it appealing to the majority of [web framework/abstraction] users.
>
> What are those goals?

I think the most interesting one that has yet to be implemented is fast, multiple destination COPY support. Currently, COPY is supported, but a bytes() object is allocated for each row, so it's currently not efficient for moving data(pg-to-pg ETL sans the T? =). While some C is still needed to make it properly efficient, it's primarily to keep track of the COPY's state and to update stats. This is pretty useless to a django user... Well, I suppose it might be interesting if COPY OUT could target [or transform into] JSON, but idk...

The general, ongoing goal is to implement and document *convenient* Python interfaces to PostgreSQL features. A, perhaps uninteresting, case being "supporting" advisory locks. I was thinking a context manager, but it might just be something as trivial as an additional method on the connection(very simple/direct binding).

Some "fuzzy" goals: twisted support, some asynchronous interfaces, and greater user control over type I/O. The first, twisted, mostly interests me as an exercise. The second, async interfaces, scares me as it took me some time just to feel "not unhappy" with the blocking APIs. The third will probably happen, but it's going to be a while.

I also have some goals not directly related to a driver. postgresql.unittest is currently only used internally, but I hope to document it some day soon so that people can write Python unittest.TestCase's that auto-magically build out a target cluster(~pg_regress/pgTap for Python?). Well, it works, but it's not documented and the APIs haven't been given much thought. Generally, basic cluster management tools for Python. (At one point I tried to write a programmer's HBA editor, but I think I hurt myself trying to figure out rule reduction.. That is, it was trying to be smarter than "insert/delete rule at position x".)

Well, these are the ones that come to mind, atm, but I don't think there's much beyond them.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-02-07 05:01:08 Re: [PATCH] Provide rowcount for utility SELECTs
Previous Message Josh Berkus 2010-02-07 04:06:16 Re: Confusion over Python drivers