Re: Documentation about PL transforms

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