> 1. I am not sure if get_call_trftypes is a good name - the prefix > get_call > is used when some runtime data is processed.
I guess I hadn't caught on that the prefix carried that meaning. To me, it appeared to be a prefix used to avoid being specific to 'function' or 'procedure'.
I am sure this function is in Postgres significantly longer than Postgres has support for 'procedures'.
> This function just returns > reformatted data from the system catalogue. Maybe > get_func_trftypes_list, > or just replace function get_func_trftypes (now, the list is an array, > so > there should not be performance issues). For consistency, the new > function > should be used in plperl and plpython too. Probably this function is > not
If it is acceptable to replace get_func_trftypes like that, I can produce such a patch.
> 2. > > + It also contains the OID of the intended procedural language and > whether > + that procedural language is declared as > <literal>TRUSTED</literal>, > useful > + if a single inline handler is supporting more than one procedural > language. > > I am not sure if this sentence is in the correct place. Maybe can be > mentioned separately, > so generally handlers can be used by more than one procedural language. > But > maybe > I don't understand this sentence.
My point was that, if the structure did /not/ include the OID of the PL and its TRUSTED property, then it would not be possible for a single inline handler to support more than one PL. So that is why it is a good thing that those are included in the structure, and why it would be a bad thing if they were not.
Would it be clearer to say:
It also contains the OID of the intended procedural language and whether that procedural language is declared as <literal>TRUSTED</literal>. While these values are redundant if the inline handler is serving only a single procedural language, they are necessary to allow one inline handler to serve more than one PL.