Could print-schema print some domain types as is instead of defaulting to underlying implementation?

[lsunsi]

Hey, long time diesel user here.

In my company we started using postgres domains a lot for things like "positive integer" or "non empty string" and things like that. With diesel print-schema, it works fine because diesel outputs the underlying types, which works for us.

We use enums a lot too, and enums output types that we have to implement the diesel traits for to be useful. This also works pretty great for us, so my idea here is: could print-schema render a domain type as is, so we could fill out the diesel implementation for it?

For example, if we have a "positive_bigint" domain type, having a PositiveBigint type coming from diesel would let us use the type inside the codebase knowing it can never be negative because the domain guarantees it and the type carries it's meaning inside the codebase.

This feature could work as a global opt-in (render all domains as new types) or just local opt-in (adding names of domains that should be new types). If this is something that'd make sense, I'd be happy to work on it and provide a PR!

PS: This idea could also work in general if diesel print-schema had a way to "map" some types or even some columns to specific types, allowing more configuration on the schema rendered without having to avoiding the print-schema render entirely. But I digress.

[weiznich]

So I had a short look at how domain types are treated by postgresql and why it works that way it currently works. It turns out that these types are essentially just type aliases with some additional check constraint from postgres point of view. That means it internally stores this domain types just as the underlying type and "just" performs these checks on modification/insert.
Diesel-CLI just queries the postgres information_schema for information about tables and columns. The relevant query is here:

diesel/diesel_cli/src/infer_schema_internals/pg.rs

Lines 101 to 111 in 55ca02b

	let query = columns
	.select((
	column_name,
	udt_name,
	udt_schema.nullable(),
	__is_nullable,
	character_maximum_length,
	col_description(regclass(table), ordinal_position),
	))
	.filter(table_name.eq(&table.sql_name))
	.filter(table_schema.eq(schema_name));

For a domain type postgres will there just return the underlying type and not the domain type, therefore diesel-cli will just treat them as "normal types". Now it seems like the columns view that is queried there also has a domain_type and domain_schema column that is null for non-domain types and otherwise set with the right name. So supporting this might be as simple as changing that qury to do a COALESCE(domain_name, udt_name) there instead (+ adding some configuration options and write some tests). The default value for the new config option should be the current behavior. This likely needs to add the relevant columns to this table! call. I'm happy to merge a PR for that.

PS: This idea could also work in general if diesel print-schema had a way to "map" some types or even some columns to specific types, allowing more configuration on the schema rendered without having to avoiding the print-schema render entirely. But I digress.

Yes something like that would be a good extension, also for other DBMS that have their own type mapping quirks. We already had some discussion about that in #4113 (comment), but so far noone had the capacity to implement that. Again that's something we are happy to accept contributions for, but that's likely a much larger task than simply adding support for domain types in the linked query.

[lsunsi]

Nice, I was glad the idea made sense! I took the liberty to implement a draft of what the feature could be, do you mind looking it over? Is that in the direction you thought of? #4594 I added some questions to be discussed further on the PR itself.