| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | James Pye <lists(at)jwp(dot)name> |
| Subject: | Re: WIP: plpython3 |
| Date: | 2009-07-24 08:21:19 |
| Message-ID: | 200907241121.19524.peter_e@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Friday 24 July 2009 01:23:40 James Pye wrote:
> Here are the features that I plan/hope to implement before submitting
> any patch:
>
> * Native Typing [Python types that represent Postgres types]
> * Reworked function structure (Python modules, not function fragments)
> * Improved SQL interfaces (prepared statement objects[2])
> * Better SRF support(?) (uses iterators, will support composites,
> vpc & mat)
> * Direct function calls (to other Postgres functions)
> * IST support (with xact(): ...)
> * Full tracebacks for Python exceptions(CONTEXT support)
> * Cached bytecode (presuming a "procache" attributes patch would be
> acceptable[3])
While various of these ideas may be good, I think you are setting yourself up
for a rejection. There is a lot of plpython code already out there, and many
years have gone into debugging plpython to work well, so rewriting everything
and setting everyone up for a flag day, or requiring the parallel maintenance
of old and new versions of plpython is not going to work. Plus, tying all of
this up with Python 3 will make totally sure that no one expect a minority
will be able to use it.
As far as I can tell, most of the features you list above could very well be
implemented in the current language handler, using separate, isolated patches.
I don't see why everything needs to be written from scratch.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikhil Sontakke | 2009-07-24 08:45:49 | Re: [PATCH] DefaultACLs |
| Previous Message | Greg Williamson | 2009-07-24 08:07:54 | Re: SE-PostgreSQL Specifications |