Cool... will get them added.
On 4/23/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> I hope I'm not too late.
>
> Jonah H. Harris wrote:
> > On 4/19/06, John DeSoi <desoi@pgedit.com> 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
>
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324