Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nG8Qi-0000fr-Lj for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Feb 2022 23:55:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nG8Qh-0003ca-4B for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Feb 2022 23:55:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nG8Qg-0003cR-F4 for pgsql-hackers@lists.postgresql.org; Fri, 04 Feb 2022 23:55:50 +0000 Received: from anastigmatix.net ([68.171.219.55]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nG8Qb-0001tZ-JI for pgsql-hackers@postgresql.org; Fri, 04 Feb 2022 23:55:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anastigmatix.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jwhW9QIK+3G+ZEZtQrky3oJuQ8X14y0GWquJSfF+x84=; b=S8tREvUsrMMKo2DIQ1UiGncMNC MdFUGKz5cy9+MWacp8pB0PWr+/bVThaBpV2QIRCznWS0pQ/KVLTTTNvzMm4npdmM2wbPK2fdpGNwr Uv4YDJHKWRaKXjXuX7+lgMsFJozYwQEXkLpEHG0myQtgCVYYNQS0sspZv7yiZHE4w/a4L7uD1xzBS SedEbFsyzrlcGomGpBP34pTyIr8ymjLmXyXQc2V8O70vNh7ZY2BDIjREnvzag9YhGT+ByG0pbbr+i Ogz+ECVYtmqOHPUKl2VHeB8v3WAUiPzhn0D49jZpQpRjrPbO3wgv2MRf3KNN/6n2NrrCMk5c3h753 fomy3thg==; Received: from 50-102-16-206.prtg.in.frontiernet.net ([50.102.16.206]:37728) by bay.acenet.us with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nG8QY-00AUBR-Qv for pgsql-hackers@postgresql.org; Fri, 04 Feb 2022 18:55:43 -0500 From: Chapman Flack Subject: Documentation about PL transforms X-Enigmail-Draft-Status: N1110 To: PostgreSQL Hackers Message-ID: <61FDBCFE.3090800@anastigmatix.net> Date: Fri, 4 Feb 2022 18:55:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bay.acenet.us X-AntiAbuse: Original Domain - postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Get-Message-Sender-Via: bay.acenet.us: authenticated_id: chap@anastigmatix.net X-Authenticated-Sender: bay.acenet.us: chap@anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, It looks to me as if the transforms feature for PLs was added in cac7658, and support was added to plperl and plpython at that time, with documentation added for CREATE FUNCTION, CREATE/DROP TRANSFORM, and the catalogs, but nothing was added at that time to plhandler.sgml to clarify that a PL handler itself must add code to look up and apply such transforms, or nothing happens. Without that information, a reader not in the know (it happened to me) could get the idea from the CREATE TRANSFORM docs that the support is more general than it is, and an incoming argument could already contain the 'internal' something-specific-to-the-language-implementation returned by a specified transform. (Which does lead to follow-on questions like "who says an arbitrary language implementation's transform result could be safely represented in an mmgr-managed argument list?"—it really does make better sense upon learning the PL handler has to do the deed. But I haven't spotted any place where the docs *say* that.) 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.) 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? (I checked a couple obvious places like CREATE OPERATOR, CREATE FUNCTION, CREATE TYPE but did not see similar examples). 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. Regards, -Chap