I hope I'm not too late. Jonah H. Harris wrote: > On 4/19/06, John DeSoi <[EMAIL PROTECTED]> wrote: > > Alvaro indicated he would be willing to provide direction on this > > with testing support from me. He also said there are several other > > possible PL/PHP issues that would warrant a SoC project. > > Cool... let's get 'em all listed here so we can move forward.
The following is all PL/php related, in no particular order: 1. Add support for IN/OUT parameters, and named parameters. This should be easy to do, the majority of needed infraestructure in PL/php is there already. It only needs a bit more love. 2. Clean up memory usage. Both compilation and execution of a function should happen on separate, maybe temporary, memory contexts; and provide adequate cleanup for both (for example when a function is recompiled). 3. Enable it to build separate from the Apache SAPI. 4. Allow huge resultsets to be processed by providing an option to transparently use a cursor to fetch results partially, when spi_exec() is called. 5. Clean up the plphp_proc_desc struct. This involves making sure we store all the info we need to know about a function; no more, no less. (I think currently we store things we don't need, and we don't store some things it would be useful to know). I don't think any of these would warrant a SoC by itself. Maybe the whole bunch could, however. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
