Обсуждение: BUG #15956: Server closed unexpectedly for user-defined base type LIKE char

The following bug has been logged on the website:

Bug reference:      15956
Logged by:          Jason Kim
Email address:      jj-kim@users.noreply.github.com
PostgreSQL version: 11.4
Operating system:   OS X (and CentOS)
Description:

The following causes the server to close unexpectedly.

```
CREATE TYPE char_type;
CREATE FUNCTION char_type_in(cstring) RETURNS char_type
   LANGUAGE internal IMMUTABLE STRICT AS 'charin';
CREATE FUNCTION char_type_out(char_type) RETURNS cstring
   LANGUAGE internal IMMUTABLE STRICT AS 'charout';
CREATE TYPE char_type (
   INPUT = char_type_in,
   OUTPUT = char_type_out,
   LIKE = char
);
CREATE TABLE char_table (t char_type);
INSERT INTO char_table (t)
  VALUES ('t');
```

Here is the server close message:

```
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q
```

This is tested using Postgres v11.4 on OS X and Postgres v9.2.24 on CentOS.

PG Bug reporting form <noreply@postgresql.org> writes:
> The following causes the server to close unexpectedly.

> CREATE TYPE char_type;
> CREATE FUNCTION char_type_in(cstring) RETURNS char_type
>    LANGUAGE internal IMMUTABLE STRICT AS 'charin';
> CREATE FUNCTION char_type_out(char_type) RETURNS cstring
>    LANGUAGE internal IMMUTABLE STRICT AS 'charout';
> CREATE TYPE char_type (
>    INPUT = char_type_in,
>    OUTPUT = char_type_out,
>    LIKE = char
> );
> CREATE TABLE char_table (t char_type);
> INSERT INTO char_table (t)
>   VALUES ('t');

This is pilot error, not a server bug: you created a type that's
not compatible with the I/O functions you provided for it.

Admittedly, it's a bit of a gotcha: "LIKE = char" interprets
char as bpchar, a/k/a the SQL CHAR(n) type.  But the internal
charin and charout functions are for the single-byte "char"
type.  If we didn't have a couple decades worth of backward
compatibility to think about, we'd likely rename the latter
type, since it's a Postgres-ism not standard.

            regards, tom lane