From: Josh Berkus on

> 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?

--Josh Berkus

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on
On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen <markokr(a)gmail.com> wrote:
> This is long-term todo item for psycopg, seems offtopic
> to the "driver situation".
[...]
> This is routine bug in either app or psycopg, we have no reason
> to touch it.  The guy should report to appropriate lists.
[...]
> Long-term todo item for psycopg2, offtopic for "driver situation".
[...]
> psycopg2 has array support, I'd like to have tuple/record also.
>
> Minor todo item for psycopg, mostly but not completely offtopic
> for "driver situation".

I'm not a Python user myself, but I have trouble understanding how you
can describe bugs in one of the Python drivers as off-topic to the
Python driver situation.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on
Kevin,

> Of course all of this is from the perspective of Python users. Of
> course, you have your own features that you want from your end (from
> PostgreSQL's perspective). Perhaps this info would help you to know
> which avenue to pursue.

That's invaluable. Thanks for chiming in!

--Josh Berkus

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: James William Pye on
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(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Jeff Davis on
On Fri, 2010-02-05 at 09:19 -0500, Bruce Momjian wrote:
> My son has brought to my attention that our current crop of Python
> client libraries is inadequate/confusing. I took a look myself, and
> asked on our IRC channel, and am now convinced this area needs
> attention.

I have written up a set of guidelines for driver development based on
what I learned working on ruby-pg:

http://wiki.postgresql.org/wiki/Driver_development

Whether we take one of the existing projects and improve upon it, or
start a complete rewrite, I hope these guidelines will be a useful
destination.

Note that the ruby-pg driver doesn't 100% adhere to those standards
(encoding is the primary problem, and that will be fixed).

I would appreciate comments by anyone (Greg Sabino Mullane: I included
you in the CC because I thought you may have some input). Even if the
python driver doesn't go in that direction, it will help me improve
ruby-pg.

Regards,
Jeff Davis


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers