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.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to