On 12/06/2013 07:25 AM, Peter Eisentraut wrote:
> On Tue, 2013-11-26 at 18:10 +0100, Dimitri Fontaine wrote:
>> The problem is installing a set of extensions where some of them are
>> already using the new transform feature and some of them are not. We
>> need a way to cater with that, I think.
> Here is an idea. Add a GUC that basically says something like
> use_transforms = on|off. You can then attach that to individual
> functions, which is the right granularity, because only the function
> knows whether its code expects transforms or not. But you can use the
> full power of GUC to configure it any way you want.
It would requite the "old" extensions to be modified to have
(SET use_transforms = off) in all their definitions so that they
would not accidentally be called with use_transforms = on
from "new" functions, but else it seems like a good way to get
it done without too much effort.
> The only thing this doesn't give you is per-argument granularity, but I
> think the use cases for that are slim, and we don't have a good existing
> mechanism to attach arbitrary attributes to function arguments.
Agreed. And we are quite unlikely to need multiple transforms for
the same type in the same language.
> Actually, I'd take this two steps further.
>
> First, make this parameter per-language, so something like
> plpython.use_transforms. Then it's up to the language implementation
> how they want to deal with this. A future new language could just
> ignore the whole issue and require transforms from the start.
I do not really see much need for this, as it will need to be set for
each individual function anyway.
Actually what we could do is just declare a new "language" for this
so functions declared with "LANGUAGE plpythonu" will not be using
transforms and those with "LANGUAGE plpythonuxf" will use it.
This would only need one extra function to be defined in source
code, namely the compile function for the "new" language".
Some not-transforms-related wild ideas follow :)
Adding a new language would also be a good way to fix the bad syntax
choices in pl/python which require code manipulation before compiling .
I came up with this idea after seeing how pl/jsv8 supports multiple
JavaScript-based languages (standard JavaScript, CoffeeScript, LiveScript)
from the same codebase.
Taking the plv8 ideas further we could also create a JavaScript-based
"sandboxed python" using thins like skulpt and pyjamas which compile
python source code to JavaScript VM and inherit all the sandboxing of
v8.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ