Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> On the other hands, interpret_AS_clause() raises an ereport if SQL
> function tries to use probin except
> for C-language. Is it illegal for other languages to use probin field
> to store something useful?
Well, there's no convention about how to use it.
> In my case, PL/CUDA language allows to define SQL function with a CUDA
> code block.
> It saves a raw CUDA source code on the pg_proc.prosrc and its
> intermediate representation
> on the pg_proc.probin; which is automatically constructed on the
> validator callback of the language
> handler.
I have precisely zero sympathy for such a kluge. The validator exists
to validate, it is not supposed to modify the pg_proc row.
We could imagine extending the PL API to allow storage of a compiled
version in probin, but overloading the validator isn't the way to do
that IMO. I'd prefer to see a separate "compile" function for it.
Existence of a compile function could be the trigger that instructs,
eg, pg_dump not to include the probin value in the dump.
(There once was a LANCOMPILER option in the CREATE LANGUAGE syntax,
which I imagine was meant to do something like this, but it was never
fully implemented and we got rid of it years ago.)
The bigger question though is whether it's really worth the trouble.
All existing PLs deal with this by caching compiled (to one degree
or another) representations in process memory. If you keep it in
probin you can save some compilation time once per session, but on the
other hand you're limited to representations that can fit in a flat blob.
regards, tom lane