[Plperlng-devel] target July 1!

Andrew Dunstan andrew at dunslane.net
Thu Apr 28 14:10:19 GMT 2005


from Bruce on -hackers:

The current core proposal is to do feature freeze on July 1, with the
understanding that we will be done most of the items above by then and
have the outstanding patches applied.

For me this will be complicated by the fact that I will be away in Australia for the 1st 2 weeks of June, and while I will be in contact I don't expect to be doing much postgres work!

So, I have two questions:
. what features do we have ready to go now? Let's start preparing patches and feeding them upstream right away. Instead of jumbo patches, one patch per feature would be ideal. Any patch should include both a test and documentation - if we need to split those tasks let's get on it right away.
. what else can we get done. Ideally, we should set a target date somewhat before the feature freeze - core doesn't like being hit with unadvertised features at the last minute.

Also, here's a quote from my new blog ( http://people.planetpostgresql.org/andrew/index.php ):

----

Josh Berkus was just having some fun with a plperl function that kept 
state between calls. After I helped him straighten out the logic it 
turned out he had no way to initialise the state. Well, I wrote a 
function for him to initialise it,. He says he can’t do any straight 
procedural calls, and since this function had to be called from the 
outer query of a nested set, he called the initialisation function from 
the inner query - which worked but is a hack that was a lucky artifact 
of the fact that we had this place to call it.

More generally, we would like to be able to set a variable that says 
which is the first call, so we can put the init code right in the 
function that relies on it. There are some nasty cases, though.
Do any of these have more than one call where the init should be set?

    * |select foo(x), foo(y) from blurfl|
    * |select foo(x) from (select foo(y) as x from blurfl) as d|
    * |select foo(x) from blurfl where foo(x) = foo(y)|

Thinking up other interesting cases should not be too hard.

Nice problem.

Josh says PL/R does set such a var - must ask Joe Conway what it does.

---

any thoughts?

cheers

andrew



More information about the Plperlng-devel mailing list