https://www.postgresql.org/docs/13/sql-createtype.html The input_function converts the type's external textual representation to the internal representation used by the operators and functions defined for the type. output_function performs the reverse transformation. The input function can be declared as taking one argument of type cstring, or as taking three arguments of types cstring, oid, integer. The first argument is the input text as a C string https://www.postgresql.org/docs/13/sql-createtype.html This example creates the base data type box and then uses the type in a table definition:
CREATE TYPE box;

CREATE FUNCTION my_box_in_function(cstring) RETURNS box AS ... ;
CREATE FUNCTION my_box_out_function(box) RETURNS cstring AS ... ;

CREATE TYPE box (
INTERNALLENGTH = 16,
INPUT = my_box_in_function,
OUTPUT = my_box_out_function
);

CREATE TABLE myboxes (
id integer,
description box
);
Проверяем работоспособность приведённого примера:


Таким образом, имеем 2 противоречия справки фактическому поведению.
И как так можно работать, когда ничего не работает ???

Т.е. PLPGSQL в отличие от SQL, может принимать cstring , но типы-пустышки по-прежнему возвращать не может.

Вопросы :
1 ) Тогда как объявить функции INPUT и OUTPUT для нового типа ?
2 ) Как заставить SQL принимать строки cstring ? Т.к. SQL, судя по всему, работает быстрее PLPGSQL

" Тип-пустышку " функция возвращать не может. Значит, нужно каким-то волшебным способом создать " тип в виде оболочки ". К сожалению, ни в справке, ни в интернете нет информации о том, какую форму должна иметь эта оболочка - форму домика с крышей, форму пузырька или форму плюшки. LANGUAGE SQL наверняка скушал бы " тип в форме плюшки ", но он не принимает строки cstring . LANGUAGE PLPGSQL не сможет обеспечить сохранность " типа в форме пузырька ", т.к. принимает строки cstring . Остаётся только домик с крышей . Но построить такую сложную конструкцию на SQL ещё никому не удавалось...

Павел ЛузановТекст ошибки "SQL-функции не могут иметь аргументы типа cstring" говорит о том, что такую функцию нельзя писать на SQL.И на PGPLSQL тоже: " функции PL/pgSQL не могут возвращать тип ... ".

авторBefore PostgreSQL version 8.2, the shell-type creation syntax CREATE TYPE name did not exist...
Also, to avoid accidentally cluttering the catalogs with shell types as a result of simple typos in function definitions, a shell type will only be made this way when the input function is written in C.Значит, при выполнении " CREATE TYPE name; " создаётся всего-лишь тип-пустышка (empty type) , который нельзя использовать при определении функций с реализацией на SQL или PGPLSQL . И только при определении функций с реализацией на уровне C такой тип интерпретируется как тип в виде оболочки (shell-type) . До версии 8.2 такой тип всегда интерпретировался как " shell-type ".

Предложение " Before PostgreSQL version 8.2, the shell-type creation syntax CREATE TYPE name did not exist " в справке частично противоречит фактическому поведению, поскольку " CREATE TYPE name; " - это синтаксис "shell-type" только в определённой локальной ситуации, а в общем понимании (применительно ко всем случаям) - это синтаксис создания empty type .

авторСоздание по-настоящему нового типа, с описанием входных/выходных функций это весьма не тривиальная задача. Такое стоит делать только на C.Так в текущих версиях PostgreSQL сделать это не на C стало уже невозможно...

авторА в большинстве случаев достаточно уже имеющихся встроенных типов. Странно, что такая гибкая и функциональная СУБД (PostgreSQL) из коробки не имеет беззнаковых целочисленных типов и 4-байтового unix timestamp (всё это есть в MySQL).

MelkijА вот тут как раз именно потому что гибкая.Я знаю про это расширение. Поэтому, и написал "из коробки".
Любое стороннее расширение (пусть даже и за авторством одного из разработчиков PostgreSQL), может не завестись на очередном выпуске новой версии PostgreSQL. А если на базе этих типов построены другие функции и типы, то вся база капитально "ляжет".

P.S . Не понятно, сколько ещё будет упираться команда PostgreSQL от включения этих типов в базовую сборку.
Дополнительно ещё и utimestamp / utimestamptz нужно добавить. Незачем расходовать больше памяти, чем для этого требуется (речь о распухании БД и индексов от 8-байтовых полей).

Читал я это объяснение:
1 ) Аргументы "против" там приводятся в отношении расширения, а не нативной реализации.
2 ) Что касается нативной реализации, то " This module solves that problem by generating most of the code automatically " - применимо как в отношении расширения, так и в отношении нативной реализации.

Таким образом, доводы против нативной реализации в этих объяснениях отсутствуют.