On Feb 1, 2010, at 12:18 PM, James William Pye wrote:
Right now, I'm trying to trim some of the easy issues[1] and getting a
project web page up. I expect to be able to make a release soon, and I'll
follow-up to this thread when I do.
Well, I ended up doing some others things at that point
On Sat, Jan 23, 2010 at 3:28 PM, James William Pye li...@jwp.name wrote:
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
Here's the trigger example which should help reveal some of the advantages of
native typing. This is a
On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly. If the user community grows or
if one of the committers takes an interest in
On Mon, Feb 1, 2010 at 1:29 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly.
Robert Haas robertmh...@gmail.com writes:
To recap the votes I've seen on this thread and elsewhere:
- JD is very enthusiastic about this patch
- So is the OP
- Josh Berkus and I are both dubious about having two in-core PL/pythons
- Peter Eisentraut prefers the original implementation
-
Tom Lane escribió:
The first thought that comes to mind is plpythonng, following a
tradition established by the tcl client rewrite among others ... but
that double n doesn't read very well.
plpythoNG perhaps?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
On Mon, Feb 1, 2010 at 2:00 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Tom Lane escribió:
The first thought that comes to mind is plpythonng, following a
tradition established by the tcl client rewrite among others ... but
that double n doesn't read very well.
plpythoNG perhaps?
On Feb 1, 2010, at 10:53 AM, Tom Lane wrote:
The first thought that comes to mind is plpythonng, following a
tradition established by the tcl client rewrite among others ... but
that double n doesn't read very well.
And without it, you have a thong. Who's going to wear that?
Best,
David
--
On Feb 1, 2010, at 11:29 AM, Joshua D. Drake wrote:
On Mon, 2010-02-01 at 13:20 -0500, Robert Haas wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly. If the user community
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly.
FWIW, I am very excited about this patch and would be happy to review
it but have been very busy over the past month. If I can
On Mon, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly.
FWIW, I am very excited about this patch and would be happy to review
On Mon, Feb 1, 2010 at 3:01 PM, Nathan Boley npbo...@gmail.com wrote:
On the basis of all of the foregoing, I don't think we can consider
this patch further for this CommitFest and will update
commitfest.postgresql.org accordingly.
FWIW, I am very excited about this patch and would be happy
I think it would be great for you to review it... I doubt that will
cause it to get committed for 9.0, but my doubt is no reason for you
to hold off reviewing it.
I assumed so, but the pretense of a chance will probably help to motivate me :-)
I'll have something by Thursday, and then
On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very unwieldy. For this reason I often
use pl/perl or pl/pgsql for problems that, outside of postgres, I
would always use python.
I find that curious,
On Mon, 2010-02-01 at 22:35 +0200, Peter Eisentraut wrote:
On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very unwieldy. For this reason I often
use pl/perl or pl/pgsql for problems that, outside of
Peter Eisentraut escribió:
On mån, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very unwieldy. For this reason I often
use pl/perl or pl/pgsql for problems that, outside of postgres, I
would always use
Alvaro Herrera wrote:
Peter Eisentraut escribi?:
On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very unwieldy. For this reason I often
use pl/perl or pl/pgsql for problems that, outside of
On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Peter Eisentraut escribi?:
On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very unwieldy. For this reason I often
Joshua D. Drake wrote:
On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Peter Eisentraut escribi?:
On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I have
often found pl/python to be very
On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote:
I would love to know why PL/Python can't be incrementally improved like
the rest of our code.
It has been. That is exactly what PeterE has been doing.
However, if you look at this whole thread, you will see the James has a
On Feb 1, 2010, at 2:13 PM, Bruce Momjian wrote:
I would love to know why PL/Python can't be incrementally improved like
the rest of our code.
AFAICT, there are two primary, perhaps identifying, parts to a PL extension:
code management (compilation, execution, etc) and type I/O (conversion in
On 2/1/10 1:39 PM, Joshua D. Drake wrote:
On Mon, 2010-02-01 at 16:31 -0500, Bruce Momjian wrote:
I would love to know why PL/Python can't be incrementally improved like
the rest of our code.
It has been. That is exactly what PeterE has been doing.
However, if you look at this whole
On Mon, Feb 1, 2010 at 4:30 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2010-02-01 at 16:13 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Peter Eisentraut escribi?:
On m?n, 2010-02-01 at 12:01 -0800, Nathan Boley wrote:
I code nearly exclusively in python and C, but I
On Feb 1, 2010, at 1:23 PM, Nathan Boley wrote:
I think it would be great for you to review it... I doubt that will
cause it to get committed for 9.0, but my doubt is no reason for you
to hold off reviewing it.
I assumed so, but the pretense of a chance will probably help to motivate me
On Sat, 2010-01-23 at 13:28 -0700, James William Pye wrote:
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
So is there any more movement on this? Peter, what do you think? I
mean... he has put in quite a bit of effort here. How
On Wed, 2010-01-20 at 19:32 -0700, James William Pye wrote:
Apologies ahead of time for the lack pretty graphs. =)
I used two different builds/installations of PG to test as the PL names
conflict. Both were compiled with the following CFLAGS(pg_config output):
-O2 -Wall
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
Here's the trigger example which should help reveal some of the advantages of
native typing. This is a generic trigger that constructs and logs
manipulation statements for simple
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
What I would (as a non hacker) would look for is:
(1) Generalized benchmarks between plpython(core) and plpython3u
I know a lot of these are subjective, but it is still good to see if
there are any curves or points that bring the
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
So far, I have three specific examples in mind:
The first will illustrate the advantages of function modules wrt setup code in
the module body. Primarily this is about convenience.
On Jan 14, 2010, at 7:08 PM, Greg Smith wrote:
So more targeted examples like you're considering now would help.
Here's the first example. This covers an advantage of function modules.
This is a conversion of a plpythonu function published to the wiki:
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye li...@jwp.name wrote:
The effect of this is that every time the FUNCTION is called from PG, the
import statements are ran, a new class object, UrlOpener, is created, and a
new function object, translate, is created. Granted, a minor amount of
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
What I would (as a non hacker) would look for is:
(1) Generalized benchmarks between plpython(core) and plpython3u
I know a lot of these are subjective, but it is still good to see if
there are any curves or points that bring the
On Fri, 2010-01-15 at 13:26 -0700, James William Pye wrote:
On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote:
What I would (as a non hacker) would look for is:
(1) Generalized benchmarks between plpython(core) and plpython3u
I know a lot of these are subjective, but it is still good
* Greg Smith g...@2ndquadrant.com [100114 02:17]:
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
On Jan 14, 2010, at 12:17 AM, Greg Smith wrote:
Code samples.
Okay.
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,
On Thu, 2010-01-14 at 05:39 -0700, James William Pye wrote:
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
James William Pye wrote:
The documentation is back up, so please be sure to look at the numerous examples provided
therein. In addition to that, I'll try to get some contrasting examples posted as a
follow-up to an earlier message. In plpython you do X whereas in plpython3 you do
Y.
I
On Tue, 2010-01-12 at 20:06 -0800, Josh Berkus wrote:
So it seems to me that the threshold question for this patch is - do
we think it's a good idea to maintain two implementations of PL/python
in core?
Not really, no. This is why we need PGAN ;-)
If the new implementation is *better*
On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
I think it is important to remember that the current version of
PL/python is pretty weak compared to its counter parts (Specifically
PL/Perl).
How so?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, 2010-01-13 at 19:53 +0200, Peter Eisentraut wrote:
On ons, 2010-01-13 at 09:47 -0800, Joshua D. Drake wrote:
I think it is important to remember that the current version of
PL/python is pretty weak compared to its counter parts (Specifically
PL/Perl).
How so?
O.k. you may have
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
If there is, I am still all for it, but I am a python bigot.
Yeah, it's just my viewpoint that we don't want 2 python
On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus j...@agliodbs.com wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
If there is, I am still all for it, but I am a python
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
Doing so, succinctly, is unfortunately difficult.
It is primarily a
On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
On Jan 13, 2010, at 11:08 AM, Joshua D. Drake wrote:
My argument would be now, what is the benefit of the James Pye version
over our version. James can you illustrate succinctly why we should be
supporting a new version?
Doing
On ons, 2010-01-13 at 12:12 -0800, Joshua D. Drake wrote:
On Wed, 2010-01-13 at 13:06 -0700, James William Pye wrote:
Function Modules:
- Does away with the need for GD/SD (more natural Python environment).
- Allows tracebacks (tracebacks are useful, right?) to implemented easily.
-
On Wed, 2010-01-13 at 23:27 +0200, 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, 75% of which is subjective and tends to
use semi-buzzwords,
On ons, 2010-01-13 at 13:33 -0800, Joshua D. Drake wrote:
The only thing I am currently looking for is an objective review of the
patch based on the benefits it provides.
Right, but I was opining that such a vague feature listing is not
adequate for that.
I can tell you that if the Pye
patch
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
On Jan 13, 2010, at 12:15 PM, Robert Haas wrote:
1. It's not just a rewrite, it's an incompatible rewrite that will
present significant user-visible behavioral differences. So replacing
the current implementation wholesale would produce massive breakage
for anyone actually using PL/python in
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,
On Sun, Dec 13, 2009 at 5:02 PM, James Pye li...@jwp.name wrote:
On Nov 19, 2009, at 5:41 PM, James Pye wrote:
Here's my latest patch.
Fixed a lot of memory/reference leaks, added some minor features(mostly
around Arrays), and filled in more documentation.
At this point, I don't have any
So it seems to me that the threshold question for this patch is - do
we think it's a good idea to maintain two implementations of PL/python
in core?
Not really, no. This is why we need PGAN ;-)
If the new implementation is *better* that the existing PL/python, I
could see eventually
52 matches
Mail list logo
