Subject: Re: Documentation about PL transforms
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <61FDBCFE.3090800@anastigmatix.net>
 <efbdcf7e-9b39-631b-011a-b75cb58e1dd3@enterprisedb.com>
 <62017DB3.5020900@anastigmatix.net>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <6213FFA0.1080202@anastigmatix.net>
Date: Mon, 21 Feb 2022 16:09:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <62017DB3.5020900@anastigmatix.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6213FFA0.1080202%40anastigmatix.net>
Precedence: bulk

On 02/07/22 15:14, Chapman Flack wrote:
> I'll work on some doc patches.

It seems a bit of an impedance mismatch that there is a get_func_trftypes
producing a C Oid[] (with its length returned separately), while
get_transform_fromsql and get_transform_tosql both expect a List.

There is only one in-core caller of get_func_trftypes (it is
print_function_trftypes in ruleutils.c), while both in-core PLs that
currently support transforms are reduced to rolling their own List by
grabbing the protrftypes Datum and hitting it with oid_array_to_list.

Would it be reasonable to deprecate get_func_trftypes and instead
provide a get_call_trftypes (following the naming of get_call_result_type
where _call_ encompasses functions and procedures) that returns a List,
and use that consistently?

Regards,
-Chap