Message-ID: <efbdcf7e-9b39-631b-011a-b75cb58e1dd3@enterprisedb.com>
Date: Mon, 7 Feb 2022 16:59:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.5.1
Subject: Re: Documentation about PL transforms
Content-Language: en-US
To: Chapman Flack <chap@anastigmatix.net>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <61FDBCFE.3090800@anastigmatix.net>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <61FDBCFE.3090800@anastigmatix.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/efbdcf7e-9b39-631b-011a-b75cb58e1dd3%40enterprisedb.com>
Precedence: bulk

On 05.02.22 00:55, Chapman Flack wrote:
> I'm thinking plhandler.sgml is the only place that really needs to be
> said; readers looking up CREATE TRANSFORM and using an existing PL that
> supports it don't need to know how the sausage is made. (Maybe it is
> worth mentioning there, though, that it isn't possible to develop
> transforms for an arbitrary PL unless that PL applies transforms.)

makes sense

> I noticed the CREATE TRANSFORM docs show the argument list as
> (argument_type [, ...]) even though check_transform_function will reject
> any argument list of length other than 1 or with type other than internal.
> Is that an overly-generic way to show the syntax, or is that a style
> with precedent elsewhere in the docs?

That could be corrected.

> As long as a PL handler has the sole responsibility for invoking
> its transforms, I wonder if it would make sense to allow a PL to
> define what its transforms should look like, maybe replacing
> check_transform_function with a transform_validator for the PL.
> I'm not proposing such a patch here, but I am willing to prepare
> one for plhandler.sgml and maybe pltemplate.c documenting the current
> situation, if nobody tells me I'm wrong about something here.

Maybe.  This kind of thing would mostly be driven what a PL wants in 
actual practice, and then how that could be generalized to many/all PLs.