CREATE_TRANSFORM(7pg17)

🦋 CREATE_TRANSFORM(7) 🦋

Okay bestie, welcome to CREATE_TRANSFORM(7) — the PostgreSQL 17.11 page that's literally all about defining a new transform. Pull up a chair, grab a strawberry 🍓, and let's get into it.

💖 NAME 💖

CREATE_TRANSFORM — define a new transform, periodt 💅

✨ SYNOPSIS ✨

CREATE [ OR REPLACE ] TRANSFORM FOR type_name LANGUAGE lang_name (
    FROM SQL WITH FUNCTION from_sql_function_name [ (argument_type [, ...]) ],
    TO SQL WITH FUNCTION to_sql_function_name [ (argument_type [, ...]) ]
);

🫶 DESCRIPTION 🫶

So CREATE TRANSFORM defines a new transform. CREATE OR REPLACE TRANSFORM will either create a new transform or replace an existing definition. Iconic, flexible, we love to see it. 💖

A transform specifies how to adapt a data type to a procedural language. For example, when you're writing a function in PL/Python using the hstore type, PL/Python has no prior knowledge how to present hstore values in the Python environment. Language implementations usually default to using the text representation, but that is inconvenient when, for example, an associative array or a list would be more appropriate. It's giving "why is this still a string" energy, ngl. 😭

A transform specifies two functions:

• A “from SQL” function that converts the type from the SQL environment to the language. This function will be invoked on the arguments of a function written in the language. It's the glow-up from SQL-land into language-land. ✨
• A “to SQL” function that converts the type from the language to the SQL environment. This function will be invoked on the return value of a function written in the language. It's the comeback journey back to SQL-land. 💫

It is not necessary to provide both of these functions. If one is not specified, the language-specific default behavior will be used if necessary. And lowkey, to prevent a transformation in a certain direction from happening at all, you could also write a transform function that always errors out. That's the no ❤️ option, iykyk. 🙈

To be able to create a transform, you must own and have USAGE privilege on the type, have USAGE privilege on the language, and own and have EXECUTE privilege on the from-SQL and to-SQL functions, if specified. Permission check: main character energy only. 👑

🌸 PARAMETERS 🌸

• type_name — the name of the data type of the transform. The type is literally the main character here. 💅
• lang_name — the name of the language of the transform. This is where the type is heading, bestie. 🦋
• from_sql_function_name[(argument_type [, ...])] — the name of the function for converting the type from the SQL environment to the language. It must take one argument of type internal and return type internal. The actual argument will be of the type for the transform, and the function should be coded as if it were. (But it is not allowed to declare an SQL-level function returning internal without at least one argument of type internal.) The actual return value will be something specific to the language implementation. If no argument list is specified, the function name must be unique in its schema. It's giving very specific signature requirements, and we respect it. 🎀
• to_sql_function_name[(argument_type [, ...])] — the name of the function for converting the type from the language to the SQL environment. It must take one argument of type internal and return the type that is the type for the transform. The actual argument value will be something specific to the language implementation. If no argument list is specified, the function name must be unique in its schema. Same energy, opposite direction. 🔁

🎀 NOTES 🎀

Use DROP TRANSFORM to remove transforms. That's it, that's the note. Short and slay. 💅

🔥 EXAMPLES 🔥

Okay bestie, example time. To create a transform for type hstore and language plpython3u, first set up the type and the language:

CREATE TYPE hstore ...;

CREATE EXTENSION plpython3u;

Then create the necessary functions:

CREATE FUNCTION hstore_to_plpython(val internal) RETURNS internal
LANGUAGE C STRICT IMMUTABLE
AS ...;

CREATE FUNCTION plpython_to_hstore(val internal) RETURNS hstore
LANGUAGE C STRICT IMMUTABLE
AS ...;

And finally create the transform to connect them all together:

CREATE TRANSFORM FOR hstore LANGUAGE plpython3u (
    FROM SQL WITH FUNCTION hstore_to_plpython(internal),
    TO SQL WITH FUNCTION plpython_to_hstore(internal)
);

In practice, these commands would be wrapped up in an extension. Very "packaged and polished" of them. 🎁

The contrib section contains a number of extensions that provide transforms, which can serve as real-world examples. Go peek, bestie — real-world inspo is right there. 🌈

⭐ COMPATIBILITY ⭐

This form of CREATE TRANSFORM is a PostgreSQL extension. There is a CREATE TRANSFORM command in the SQL standard, but it is for adapting data types to client languages. That usage is not supported by PostgreSQL. So like, yes bestie, but also no — not that usage. 💀

🦋 SEE ALSO 🦋

• CREATE FUNCTION (CREATE_FUNCTION(7))
• CREATE LANGUAGE (CREATE_LANGUAGE(7))
• CREATE TYPE (CREATE_TYPE(7))
• DROP TRANSFORM (DROP_TRANSFORM(7))

---

💖 That's the whole CREATE_TRANSFORM(7) page, bestie — brought to you by the PostgreSQL 17.11 documentation, dated 2026. Now go define those transforms, and remember: the vibe is specific, the signatures are internal, and the transform is iconic. Periodt. 🫶✨