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
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 |