kevinar18(at)hotmail(dot)com (Kevin Ar18) writes:
> 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.
No, those seem like fine ways of getting a good perspective on the
I happen not to use Python much, so there's a certain aspect of "don't
care" on my part... but that doesn't imply that my "PostgreSQL
perspective" would tend to override yours. Instead, I think that the
"Python users' perspective" *is* a mighty important thing.
The interface needs aspects of "cleanness" on both sides of the
- On the Python side, it needs to "play well" in a variety of ways
that you seem to have described nicely, some technical, some
licensing oriented. Some relating to interfacing to further bits
of Python and to applications and frameworks written in Python.
- On the PostgreSQL side, there's certainly a preference for
Note that most of the issues there really lie on the Python side, which
underlines the importance of "Python users' perspective."
Further, the "ideal" and "issues/problems" that you point out all seem
reasonable. The good seems good and the bad seems like things that do
indeed need to be accepted as consequences of the good.
It will doubtless help guide assistance.
output = reverse("moc.liamg" "@" "enworbbc")
"...as a robotics designer once told me, you don't really appreciate
how smart a moron is until you try to design a robot..."
-- Jerry Pournelle
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-02-09 16:43:52|
|Subject: Re: Avoiding bad prepared-statement plans.|
|Previous:||From: Boszormenyi Zoltan||Date: 2010-02-09 16:25:02|
|Subject: Re: ERROR: could not load library "...": Exec format error|