On 2022-07-13 00:26, Pavel Stehule wrote:
> 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'.
> 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.
Regards,
-Chap