plpython3
in [PgSql]
|
From: "Joshua D. Drake" on 26 Jan 2010 18:23 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 do we get this reviewed? I asked my guys to do it, but my C guys are very Perl centric... Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 1 Feb 2010 13:20 On Sat, Jan 23, 2010 at 3:28 PM, James William Pye <lists(a)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 generic trigger that constructs and logs manipulation statements for simple replication purposes. > > The original plpython version is located here: > > http://ar.pycon.org/common/2009/talkdata/PyCon2009/020/plpython.txt > [You'll need to scroll down to the very bottom of that page.] > > > There are three points in this example that need to be highlighted: > > 1. There is no need for a "mogrify" function (see original in the above link). > 2. Attributes/columns of the records (new/old) are extracted when referenced. > 3. The comparisons in after_update uses the data type's actual inequality operator. > > The first point is true because "native typing" gives the user direct access to a given type's typoutput via ``str(ob)``. This makes constructing the PG string representation of a given object *much* easier--quote_nullable, and done. The original plpython example will need to be updated to compensate for any changes in conversion: arrays will now need special handling and MD arrays will not work at all. It also relies heavily on the Python object representation matching PG's; where that fails, special cases need to be implemented(composites, notably). All of that compensation performed in the original version is unnecessary in the plpython3 version. > > The second point touches on the "efficiency" that was referenced in an earlier message. No cycles are spent converting the contents of a container object unless the user chooses to. Naturally, there is no advantage performance-wise if you are always converting everything. > I'd wager that with triggers, it's rare that everything needs to be converted. > > The third point reveals that Postgres.Object instances--a component of native typing--use the data type's operator for inequality. It's not limited to comparisons as all available Python operators are mapped to corresponding operators in PG. For many or all primitives, there is no added value over conversion. However, this provides a lot of convenience when working with UDTs, datetime types, and geometric types. > > ...ISTM that the primary advantage of "native typing" is that we get to define the Python interface to a given Postgres data type. When I initially read the description of this patch, I had really no idea what it was about, and I have to say that over the last several weeks, the subsequent posts have increased my interest substantially, and I think it could potentially have a future in core, or in contrib. The performance gains from native typing are particularly interesting. That having been said, we don't have a reviewer for this patch, and more to the point, even if we did, I don't believe we have a COMMITTER for this patch. The only committer who has done any significant work on the existing PL/python implementation for this release is Peter Eisentraut, and he's made it pretty clear that he's not interested in this reimplementation. I personally do not know Python even as a user, let alone as a hacker, so I'm poorly qualified to review it myself. Even were it otherwise, I know that if I were to commit this I would to some degree be on the hook to maintain it forever, which is more than I really want to take on. I suspect other committers feel similarly; or if not, they haven't chimed in on any of the relevant threads to say so. 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 (if I'm not putting words into his mouth) that this might be worth considering, but not for 9.0 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 this down the road, I think we could consider it for a future release. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 1 Feb 2010 13:29 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 this down the road, I > think we could consider it for a future release. > I spoke with James offline about this as well. My understanding (correct me James) is that he is working on an implementation that can be installed via PGXS. Joshua D. Drake > ...Robert > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 1 Feb 2010 13:37 On Mon, Feb 1, 2010 at 1:29 PM, Joshua D. Drake <jd(a)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. If the user community grows or >> if one of the committers takes an interest in this down the road, I >> think we could consider it for a future release. > > I spoke with James offline about this as well. My understanding (correct > me James) is that he is working on an implementation that can be > installed via PGXS. Sounds good! ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 Feb 2010 13:53
Robert Haas <robertmhaas(a)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 > - Greg Smith thinks (if I'm not putting words into his mouth) that > this might be worth considering, but not for 9.0 One other problem with accepting this to be parallel with the existing plpython is that there's a name conflict: Peter's work to allow the existing PL to use Python 3 has already claimed the name "plpython3". Whether it's to be distributed in core or separately, I think something needs to be done about that. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |