Обсуждение: BUG #15956: Server closed unexpectedly for user-defined base type LIKE char
BUG #15956: Server closed unexpectedly for user-defined base type LIKE char
От
PG Bug reporting form
Дата:
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