>>>
>>>1) Resolve license issues (not bsd licensed)
We can make it any license we want... Right now it is PHP licensed just
because that is what seemed to make sense.
>>>2) Integrate it into the postgresql build system so it can work on all
>>>platforms.
That is up to the core.
>>>3) Make it build against different versions of php
We don't believe it should support ANYTHING but 4.3.2 or above.
>>>4) More people testing it in different situations.
Makes sense.
>>
>>Here's my list.
>>
>>Minor issues/ general code cleanup:
>>1. eliminate '//' style comments
Our programmers prefer // style comments.
>>More significant:
>>2. Add support for array conversion in-out
>>3. Add support for set-returning functions
>>4. Add support for argument/return-value polymorphism
>>5. Incorporate recent improvements in function caching (ala PL/pgSQL)
>>6. Add documentation
>>7. Add regression test support
>>8. Modify for new ereport syntax and nested error contexts
These are all good suggestions. Anybody want to help? plPHP was done
as a proof of concept more than anything else. We are concentrating
our efforts on other things.
>>
>>Most significant:
>>9. Use PHP embed API instead of the PHP CLI (command line interface)
>>10.Fix license
>
>
> Looking at the license for PHP found here:
>
> http://www.php.net/license/3_0.txt
>
> it would seem to be pretty much an apache style license that doesn't allow
> you to relicense it without permission. but it looks BSD compatible.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
