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
