Re: Documentation about PL transforms

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Chapman Flack <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-13 04:26:47
Message-ID: CAFj8pRAof_kLmVRMhZWZ6Cj9JNo-yKXs6q+X5Zcsm9i76w8_bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

I am doing an review of this patch and I have two comments

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. 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
widely used, so I don't see why we need to have two almost equal functions
in code.

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.

Regards

Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2022-07-13 04:33:18 Re: Perform streaming logical transactions by background workers and parallel apply
Previous Message David Rowley 2022-07-13 04:13:58 Re: PG15 beta1 sort performance regression due to Generation context change