Support CREATE TYPE for creating custom type

[MRGRAVITY817]

Hello, I think it would be nice to add CREATE TYPE statement for creating custom composite type.

Use cases

-- Defining composite type
CREATE TYPE inventory_item AS (
    name            text,
    supplier_id     integer,
    price           numeric
);

-- Using composite type `inventory_item`
CREATE TABLE on_hand (
    item      inventory_item,
    count     integer
);
INSERT INTO on_hand VALUES (ROW('fuzzy dice', 42, 1.99), 1000);

References

• Postgres: https://www.postgresql.org/docs/current/sql-createtype.html
• SQL server: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-type-transact-sql?view=sql-server-ver16

[rex-remind101]

Just ran into this too.

[AugustoFKL]

@MRGRAVITY817 @rex-remind101 do you have any specific type to be supported? PostgreSQL and SQL Server seem not to follow the standard, so implementing each one of them would be a task by itself, isolated from the other ones.

The standard seems to be the easiest to expand, so I'd start with it, but I want to make sure of what exactly you need.

[teenjuna]

Hey @AugustoFKL, I've also just ran into this. Could you please elaborate your question about any specific type? Personally, I just want this crate to be able to parse Postgres' CREATE TYPE ... AS (...) and CREATE TYPE ... AS ENUM (...)

[AugustoFKL]

@teenjuna I see.

The problem is, CREATE TYPE ... AS (...) follows the standard (1), but the latest not. I'm currently mostly working to try to expand our ANSII implementation, or some others as I need. Otherwise, I don't have plans to work on that.

I could work on the first one, but not the CREATE TYPE ... AS ENUM. Does that help you?

[1] : https://jakewheat.github.io/sql-overview/sql-2016-foundation-grammar.html#datetime-type

[teenjuna]

@AugustoFKL any improvement will be very helpful, thank you!

It'll be also very helpful if you will consider the possibility that AS ENUM might be implemented in the future if you implement the ANSII variant (e.g. your implementation doesn't prevent this)! I might focus on this (as well as the INSERT INTO ... RETURNING and similar popular Postgres constructs) somewhere in the end of the year.