From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | chap(at)anastigmatix(dot)net |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Documentation about PL transforms |
Date: | 2022-07-28 05:51:12 |
Message-ID: | CAFj8pRCdbDxwWL1NU1spjQher=f-wuoBzWfrTiDYS9ss2oeFDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
čt 28. 7. 2022 v 4:06 odesílatel <chap(at)anastigmatix(dot)net> napsal:
> 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'.
>
I am sure this function is in Postgres significantly longer than Postgres
has support for 'procedures'.
>
> > 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.
>
ok
Regards
Pavel
>
> Regards,
> -Chap
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-07-28 05:58:35 | Re: Handle infinite recursion in logical replication setup |
Previous Message | kuroda.hayato@fujitsu.com | 2022-07-28 05:20:00 | RE: Perform streaming logical transactions by background workers and parallel apply |