plpython3
in [PgSql]
|
From: Aidan Van Dyk on 14 Jan 2010 07:39 * Greg Smith <greg(a)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 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. Wow, I can't agree more... I've seen *so* many patches fly by that don't mean *anything* to me with the description sent to -hackers, until I find out what they actually do, or could do, until I find it in my RSS reader, via: > 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. <what he said>++ > Patch submitters should consider it a goal to make life that > easy for the reviewer stuck with checking their patch out. Yes, submitters, please specifically try to make Hubert's life easier, because we *all* will appreciate it... -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
From: James William Pye on 14 Jan 2010 07:39 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, tracebacks are useful > And even on that one, I'm not going to take your word on the superiority of your implementation. Sure, that's what review is about. No? > You're writing way over people's heads here. Okay. I guess I hoped the documentation would help clarify a lot of this, and make the advantages self-evident. On that: > (Doesn't help that your docs link at the bottom of http://wiki.postgresql..org/wiki/WIP:plpython3 is broken either). Ouch. Thanks, that's fixed now. Please take a look again: http://python.projects.postgresql.org/pldocs/plpython3.html > If one has to be a Python expert to understand your position, you've already lost. Function modules should be pretty obvious. "native typing" is a bit more difficult as a solid understanding of PG's type system is fairly important for a firm grasp. > 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. Okay. So, some examples would help. 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." Thanks. -- 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 14 Jan 2010 16:03 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 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. > > Okay. So, some examples would help. 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." > The documentation is very thorough, thank you. I am still a fan of getting this reviewed for potential inclusion but I firmly agree with what Greg has already said. 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 performance of either to light. (2) Example of the traceback facility, I know it is silly but I don't have time to actually download head, apply the patch and test this. This type of thing, showing debugging facilities within the function would be killer. (3) A distinct real world comparison where the core plpython falls down (if it does) against the plpython3u implementation I can't speak to your code quality, that is going to have to be someone else. Sincerely, Joshua D. Drake > > Thanks. -- 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: Greg Smith on 14 Jan 2010 21:08 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 had read the documentation before so it wasn't that bad that I couldn't see it. Basically, the issue I had is that it's not really clear which features are unique to this implementation that make it compelling. So more targeted examples like you're considering now would help. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com -- 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: James William Pye on 15 Jan 2010 15:26
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 performance of either to > light. I guess I could do some simple function I/O tests to identify invocation overhead(take a single parameter and return it). This should give a somewhat reasonable view of the trade-offs of "native typing" vs conversion performance-wise. One thing to keep in mind is that *three* tests would need to be done per parameter set: 1. plpython's 2. plpython3's (raw data objects/"native typing") 3. plpython3's + @pytypes The third should show degraded performance in comparison to plpythonu's whereas the second should show improvement or near equivalence. @pytypes is actually implemented in pure-Python, so the impact should be quite visible. http://python.projects.postgresql.org/pldocs/plpython3-postgres-pytypes.html I'm not sure there's anything else worth measuring. SRFs, maybe? > (2) Example of the traceback facility, I know it is silly but I don't > have time to actually download head, apply the patch and test this. Well, if you ever do find some time, the *easiest* way would probably be to download a branch snapshot from git.pg.org: http://git.postgresql.org/gitweb?p=plpython3.git;a=snapshot;h=refs/heads/plpython3;sf=tgz It requires Python 3.1. 3.0 has been abandoned by python.org. > This > type of thing, showing debugging facilities within the function would be > killer. The test output has a *lot* of tracebacks, so I'll just copy and paste one here. This one shows the traceback output of a chained exception. -- suffocates a pg error, and attempts to enter a protected area CREATE OR REPLACE FUNCTION pg_failure_suf_IFTE() RETURNS VOID LANGUAGE plpython3u AS $python$ import Postgres rp = Postgres.Type(Postgres.CONST['REGPROCEDUREOID']) def main(): try: fun = rp('nosuchfunc(int17,zzz)') except: # Should be valid, but the protection of # PL_DB_IN_ERROR should keep it from getting called. rp('pg_x_failure_suf()') $python$; SELECT pg_failure_suf_IFTE(); ERROR: database action attempted while in failed transaction CONTEXT: [exception from Python] Traceback (most recent call last): File "public.pg_failure_suf_ifte()", line 8, in main fun = rp('nosuchfunc(int17,zzz)') Postgres.Exception: type "int17" does not exist CODE: 42704 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "public.pg_failure_suf_ifte()", line 12, in main rp('pg_x_failure_suf()') Postgres.Exception [public.pg_failure_suf_ifte()] > (3) A distinct real world comparison where the core plpython falls down > (if it does) against the plpython3u implementation Hrm. Are you looking for something that plpython3 can do that plpython can't? Or are you looking for something where plpython makes the user work a lot harder? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |