Skip site navigation (1) Skip section navigation (2)

Re: plpython3

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: James William Pye <lists(at)jwp(dot)name>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, jd(at)commandprompt(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpython3
Date: 2010-01-14 07:17:04
Message-ID: 4B4EC4F0.505@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-01-14 07:19:49
Subject: Re: plpgsql: open for execute - add USING clause
Previous:From: KaiGai KoheiDate: 2010-01-14 07:04:17
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group