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

Re: plpython3

From: James William Pye <lists(at)jwp(dot)name>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: 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 04:12:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?

> 75% of which is subjective and tends to use semi-buzzwords,

You say "semi-buzzwords", I say "names". I have to call "it" something.

> such that then someone else who by his own admission
> isn't completely up to date on things says, sure, that sounds great.

Which is why we need to get some more experienced Python users involved in this.

Well, even the mileage of inexperienced users is quite useful for detecting what level of obviousness has been achieved by the features, so I'm not trying to exclude anyone.

> The current PL/Python also has, arguably, a more natural Python environment,

No, it doesn't. GD/SD are contrived in order to compensate for the very absence of that. Additionally, "modules / script files" don't return or yield.

> native typing,

Okay, that's arguably subjective, but when I write "native typing", it's wrt PG, not Python's built-in types. If that wasn't the case, I wouldn't call it anything--save "[data] conversion" when necessary--as it wouldn't be much of a feature to clamor about.

> efficiency,

Yes, as discussed in the thread before there are trade-offs here wrt how PG data is handled. It depends pretty heavily on how the parameters / query results are used.

Although, as stated before, the difference in efficiency can be rather significant in situations where conversion to built-in Python types is *not* desired.

> and explicitness.

Hrm? What is explicit about munging the source code of the procedure to make it into a function body? Perhaps you could give some examples where plpython helps promote explicitness?

And sure, I understand that other PLs do this. That may be fine for those languages, but for Python it's not, IMO.

In response to


pgsql-hackers by date

Next:From: James William PyeDate: 2010-01-14 04:39:05
Subject: Re: plpython3
Previous:From: Tom LaneDate: 2010-01-14 04:08:54
Subject: Re: Pretty printed trigger in psql

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