From: chap@anastigmatix.net
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Documentation about PL transforms
Date: Wed, 27 Jul 2022 22:05:58 -0400
Message-ID: <fc6433355d4f061ccbb1cbfad4ddd77f@anastigmatix.net> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chap@anastigmatix.net, pavel.stehule@gmail.com, peter.eisentraut@enterprisedb.com
Subject: Re: Documentation about PL transforms
In-Reply-To: <fc6433355d4f061ccbb1cbfad4ddd77f@anastigmatix.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox