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 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
On Mon, Feb 1, 2010 at 4:30 PM, 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
>>
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
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 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 th
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
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 reas
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, outsid
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 alway
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, outsid
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, b
> 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 'Retu
On Mon, Feb 1, 2010 at 3:01 PM, 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, 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 re
> 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 pro
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 com
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 Mon, Feb 1, 2010 at 2:00 PM, Alvaro Herrera
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?
ROFL. It's a s
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/
Robert Haas 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
> - Greg Smith thinks
On Mon, Feb 1, 2010 at 1:29 PM, 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 com
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
On Sat, Jan 23, 2010 at 3:28 PM, 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.
>
> Here's the trigger example which should help reveal some of the advantages of
> "native typing". This is a generic tr
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. Ho
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 -Wmissing-p
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 per
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye 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
> overhead
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:
http://wiki.postgresql.org/wiki/Google_T
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 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
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 per
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 h
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
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,
* Greg Smith [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 have *compelling*
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, b
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
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 t
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
> pa
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 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 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?
>
>
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 ma
On Wed, Jan 13, 2010 at 1:16 PM, Josh Berkus 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 bigot.
> 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, 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 ma
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 ch
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
> 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 repla
On Sun, Dec 13, 2009 at 5:02 PM, James Pye 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 more min
52 matches
Mail list logo
