Roman Rokytskyy escreveu:

> last time I was talking with Dmitry on this topic, the ideas were:
>
> a) "deprecate" UDFs (not really deprecate, they will be fully supported
> in the future, just not recommended)
>

A "LEGACY" language would do the trick here.
The legacy plugin translates new calls to old UDF calls.

Engine will know only about external functions/procedures.

> b) introduce PSQL functions
> c) merge PSQL functions and procedures into PSQL routines
> d) make PSQL just a language, let define routines in Java, .NET, Delphi,
> etc.
>
> So, let's wait for Dmitry and clear this topic first before we go to the
> system tables.
>

Ok.

>> How security is handled?
>>
>
> What exactly do you mean? In the database the normal GRANTs apply.

No. I mean security inside the Java plugin, integrating J2SE security
with database users and roles.

Just because I can define a class should not mean I'll be able to read
full hard disk inside that class.

> If you ask, whether it is possible to use Java code "implemented" for
> another database? Yes, but that was also not the target for that
> release. It is possible to extend the code to check the manifest
> embedded in the JAR file, but it is also possible to load classes from
> the database.
>

I didn't understood what you mean.

>
>> I'm using Java in Oracle, they store everything (AFAIU) in the database.
>>
>
> It is possible to load Java classes from the database (or whatever
> stream you provide - network, archive, random number generators provided
> they generate correct Java classes) , but first we have to define
> whether we are going to support similar feature for .NET (loading
> assemblies, should work, AFAIK) and Delphi (hmmm... is there any chance
> for it?)...

I think we should not use less denominator factor.

Each plugin may define best way able for his language.


Adriano