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

Re: plpython3

From: James William Pye <lists(at)jwp(dot)name>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-17 21:06:19
Message-ID: EE0EF975-4EA8-4CDD-A033-2A821D639297@jwp.name (view raw or flat)
Thread:
Lists: pgsql-hackers
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. (I'm going to send this example when I send this message)

The second is a generic after trigger that does manipulation logging for some simple replication purposes. This example will illustrate one application of "native typing" as it provides direct access to a PG type's typoutput.

The third one is a fairly old plpythonu example written by Elein that exercises SD to keep state for an aggregate. I'm expecting this to be a good candidate for showing off stateful functions.


Other things I plan to cover, but nothing specific in mind yet:

 Direct function calls
 Internal subtransactions, "with xact():" (something plpython can't do, save calling plpgsql =)

In response to

pgsql-hackers by date

Next:From: James William PyeDate: 2010-01-17 21:07:07
Subject: Re: plpython3
Previous:From: Tom LaneDate: 2010-01-17 21:05:18
Subject: Re: parallel regression test output

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