Обсуждение: Use of pg_proc.probin is legal?

Hello,

I have a question as subject line.

https://www.postgresql.org/docs/devel/static/catalog-pg-proc.html
According to the documentation, the purpose of pg_proc.probin is
introduced as follows:
| Additional information about how to invoke the function. Again, the
interpretation is language-specific.

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?

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 noticed the problematic scenario because pg_dump generates CREATE
FUNCTION statement
with two AS arguments, then pg_restore tries to run the statement but failed.

Solution seems to me either of them:
1. Admit CREATE FUNCTION with two AS arguments. If language does not
support is, probin is   simply ignored.
2. pg_dump does not dump pg_proc.probin if language is not C-language.
3. Update documentation to inform not to provide the probin if not C-language.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

2016-11-16 7:46 GMT-08:00 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>
After the thought with fresh brain, it may not be a serious problem.
Right now, it assigns dependency between a PL/CUDA function and
its helper functions (*1), then put function's OID in the intermediate
representation on the pg_proc.probin, to work even if function gets
renamed.
However, it is a situation simply we can raise an ereport if helper
function was not found, instead of the dependency mechanism.
In addition, the heavier compilation stuff is intermediate form to
the real binary form rather than the source-to-intermediate stuff,
although I don't know about other script language.

Thanks,

(*1) PL/CUDA allows to put some kind of helper function in its
program source for some purpose. For example, the directive
below suggests the runtime of PL/CUDA to allocate a particular
amount of device memory according to the result (int8) of
my_plcuda_workbuf_sz() which have identical argument set with
the PL/CUDA function.

$$ :
#plcuda_workbuf_sz my_plcuda_func_workbuf_sz :
$$

-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>