Re: plpython3

James William Pye wrote:
> On Jan 13, 2010, at 2:27 PM, Peter Eisentraut wrote:
>
>> The problem I'm having with this discussion is that every time someone
>> asks what the supposed advantages of this new Python PL are, a feature
>> list like the above is dumped,
>>
>
> I agree that this is unfortunate, but how else can we to discuss the advantages? It boils down to comparing a couple feature lists, and *maybe* some implementation details. No?
>

Code samples. You're trying to unseat a well established incumbent here,
and you're not ever going to do that with documentation. Maybe your
plpython3 has some compelling features to it. I don't know, because even
with several thousand lines of basic Python code to my credit I cannot
understand a single one of the arguments you presented for why your
implementation is better--except agreeing that, yes, tracebacks are
useful And even on that one, I'm not going to take your word on the
superiority of your implementation. You're writing way over people's
heads here. (Doesn't help that your docs link at the bottom of
http://wiki.postgresql.org/wiki/WIP:plpython3 is broken either). If one
has to be a Python expert to understand your position, you've already lost.

Python code is easy to read though. If you'd said "here's a great
example of how Function Modules are an improvement over what you can do
with the current pl/python," that would be infinitely more useful than
the list of language trivia related to them. You should be aiming to put
Peter on the spot to respond to claims you make like "you can't do this
easily with the current implementation" after showing an elegant bit of
code.

One of the things I'm increasingly frustrated by (and don't take this
personally, this is a general comment coming more from the last CF
rather than something I mean to single you out for) is how many patch
submissions we get that don't have *compelling* examples showing their
value. Have a better programming approach to something? Show me the old
way and how the new way is better. Performance improvement? Provide a
complete, self-contained example showing how to demonstrate it. New type
of feature? Cut and paste a whole session showing how it's used, with
every single command you typed after initdb.

Basically, if a reviewer can't confirm your patch is doing something
useful in five minutes and be excited that they've watched something
interesting happen, you're decreasing the chances that your patch will
ever go anywhere dramatically. I hope that everyone submitting patches
reads http://www.depesz.com/ at least once in a while. One of the things
I really enjoy about his blog is how he shows complete working examples
of so many patches. To pick a standout recent entry,
http://www.depesz.com/index.php/2010/01/03/waiting-for-8-5-exclusion-constraints/
takes "exclusion constraints"--a feature I didn't follow a bit of the
discussion about--and works through the whole feature with a series of
examples that, while still complicated, are completely self-contained
and possible to follow along until you understand how it all fits
together. Patch submitters should consider it a goal to make life that
easy for the reviewer stuck with checking their patch out.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com