Re: Documentation about PL transforms

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
>

In response to

Responses

Browse pgsql-hackers by date

  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