[feature request] support domains

[derekdreery]

Here is an explanation of domains. They are used for custom data types and are constructed from existing data types with optional constraints.

e.g. I want to use the following domain

-- Domain: public.gender

CREATE DOMAIN public.gender
  AS character(1)
  COLLATE pg_catalog."default"
  DEFAULT 'U'::bpchar
  NOT NULL
  CONSTRAINT gender_check CHECK (VALUE = 'M'::bpchar OR VALUE = 'F'::bpchar OR VALUE = 'U'::bpchar OR VALUE = 'O'::bpchar);
COMMENT ON DOMAIN public.gender
  IS 'An enum type to represent gender';

They provide additional consistency within a database. Currently, using infer_schema errors on unresolved type 'diesel::types::Gender' in the above example.

[derekdreery]

A first step in pseudecode would be (in infer_schema)

for column in columns:
    while column.type is domain
        column.type = column.type.base_type
    ... carry on as usual

This would mean they were useable in diesel, just that no extra type information is inferred.

[sgrif]

Certainly for the cases covered by that pseudocode this seems completely reasonable to add

[derekdreery]

I've thought about this some more and I'm not sure if what I suggested is better than implementing a custom data type (I think I saw ToSql and FromSql in the source). I'm not sure what the best solution.

[sgrif]

So I don't think I want to add support for "treat domain type as its base type". That check constraint you've provided means that the range of values that can be serialized differ from those of the base type. In this case you can create struct MyType;, and implement a bunch of traits example from our test suite. This is a bit verbose right now, it's going to be a focus of 1.1. #162 is the tracking issue for that.

Types that aren't in diesel::types can be used in table! by doing:

table! {
    use diesel::types::*;
    use my_types::*;

   foo {
        id -> Integer,
        bar -> MyType,
    }
}