MIME-Version: 1.0
Date: Wed, 27 Jul 2022 22:05:58 -0400
From: chap@anastigmatix.net
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>
Subject: Re: Documentation about PL transforms
In-Reply-To: 
 <CAFj8pRAof_kLmVRMhZWZ6Cj9JNo-yKXs6q+X5Zcsm9i76w8_bw@mail.gmail.com>
References: <61FDBCFE.3090800@anastigmatix.net>
 <efbdcf7e-9b39-631b-011a-b75cb58e1dd3@enterprisedb.com>
 <62017DB3.5020900@anastigmatix.net> <6213FFA0.1080202@anastigmatix.net>
 <6215246A.1000309@anastigmatix.net>
 <15aae6eba18b19579ce2568828c692bd@anastigmatix.net>
 <CAFj8pRAof_kLmVRMhZWZ6Cj9JNo-yKXs6q+X5Zcsm9i76w8_bw@mail.gmail.com>
User-Agent: Roundcube Webmail/1.5.2
Message-ID: <fc6433355d4f061ccbb1cbfad4ddd77f@anastigmatix.net>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/fc6433355d4f061ccbb1cbfad4ddd77f%40anastigmatix.net>
Precedence: bulk

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