On Jul 24, 2009, at 1:21 AM, Peter Eisentraut wrote:
While various of these ideas may be good, I think you are setting
yourself up
for a rejection.
Right, I supposed that that may be the case or at least that you would
feel this way based on your messages from the prior thread.
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.
Does this mean that you are no longer of the opinion that a separate
implementation is acceptable under the circumstances that it provides
major advantages?
Or are you of the opinion that the listed features do not provide
major advantages?
Or, perhaps, more appropriately, that the transitional features do not
provide major advantages?
[transitional features being native typing and reworked function
structure]
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.
That's why I tried to highlight native typing and the reworked
function structure.
Those two features, not to mention Python 3, make it a distinct-enough
beast to justify a different code base, IMO. The rest are icing. Icing
is delicious.
I see Python 3 as a good opportunity to change the interfaces and fix
the design of the PL.
I dunno. I have time to give it some TLC, and I'm not terribly excited
about trying to tack features onto something that I find kinda gross.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
