Re: [HACKERS] Use of pg_proc.probin is legal?
2016-11-16 7:46 GMT-08:00 Tom Lane : > Kohei KaiGai 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Use of pg_proc.probin is legal?
Kohei KaiGai 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers