Inserting into a domain type results in WrongType error

[ivan]

Using a domain like this:

CREATE DOMAIN session_id AS bytea CHECK(octet_length(VALUE) = 16);
CREATE TABLE sessions (
    session_id session_id NOT NULL PRIMARY KEY
);

And inserting a Vec<u8> into it with

conn.execute("INSERT INTO sessions (session_id) VALUES ($1)", &[&session.id]).unwrap();

results in

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Conversion(WrongType(Other { name: "session_id", oid: 25707, kind: Simple, schema: "public" }))', src/libcore/result.rs:688

That is, rust-postgres doesn't understand that the session_id is really a bytea.

Perhaps rust-postgres should look up the underlying type of the domain and use it? (I understand this might be a big feature request.)

Without underlying type detection, I think what I have to do is wrap the Vec<u8> with my own type and implement ToSql, which could be a hassle with many domains.

[sfackler]

We can find the "inner" type of a domain, and domains should probably be their own variant in Kind, but that would arguably be a change that would have to wait for a major version bump. We might be able to squeeze it in now but that would affect people that are asserting that a domain type has Kind::Simple if those people actually exist.

I'm a bit torn on what the right behavior here is with respect to Rust types. On one hand, domains seem a lot more like Rust newtypes (struct Foo(Bar)) rather than aliases (type Foo = Bar), particularly since you can attach constraints to them. In that sense, it makes sense that you'd need a wrapper type on the rust side. On the other hand, it's a real bummer to have to manually implement ToSql and FromSql for all of your wrappers. Fortunately, the behavior required would be simple enough that a straight up macro_rules! macro could generate them for you - something like domain!(struct SessionId(String) = "session_id").

If we're going to go the non-newtype route, it seems like an undue burden on ToSql and FromSql implementors to have to all deal with checking if the type passed in is a domain and doing the translation to the inner type. The driver could handle it all magically, though. If the Postgres type is a domain and the accepts function returns false, the driver could try again with the domain's inner type. That does feel very magical though.

[sfackler]

You also might be able to cast on the SQL side ... VALUES ($1::BYTEA).

[ivan]

Thanks for your thoughts on this. I don't yet know enough Rust to help figure out what kind of API would work well.

If it is any help, the only domains I've written so far involve checking that a bytea is a certain length (e.g. an encryption key), checking that a number is >= 0 or >= 1, checking that a filename text value passes CHECK(octet_length(VALUE) <= 255 AND VALUE !~ '/'), or checking that an email text value passes CHECK(VALUE ~ '@' AND VALUE = lower(VALUE)). http://www.postgresql.org/docs/9.5/static/sql-createdomain.html gives the example of a postal code.

That cast is working very conveniently, thanks for the tip!

[sfackler]

I think I am going to land the change to Kind and see if anyone complains :) Something tells me it won't be a problem, though.

[sfackler]

I added Kind::Domain and noticed something weird in the process. Postgres will report the type as the domain when the value is an input, but report the underlying type when it's an output. Not totally sure what's going on there.

[paul]

Piggybacking off this bug, I have a table with a simple text type that is merely a CHECK:

          CREATE DOMAIN bson_objectid TEXT CHECK (
            LENGTH(VALUE) = 24 AND
            VALUE ~ '^[A-Za-z0-9]{24}$'
          )

Inserting into this in the command line with a normal TEXT type works fine:

development=# \d mongo_users
                                      Table "public.mongo_users"
   Column    |            Type             |                         Modifiers
-------------+-----------------------------+-----------------------------------------------------------
 id          | integer                     | not null default nextval('mongo_users_id_seq'::regclass)
 mongo_id    | bson_objectid               | not null

INSERT INTO mongo_users (mongo_id) VALUES ('deadbeefdeafbeefdeadbeef');
INSERT 0 1

Trying to insert a string using this library results in:

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Conversion(WrongType(Other { name: "bson_objectid", oid: 42491, kind: Simple, schema: "public" }))', src/libcore/result.rs:741

It seems that rust-postgres doesn't know that a normal string is an acceptable type for the custom domain.

[paul]

Re-reading, I realize this is exactly the same bug as reported above, but I tried this against the lastest rust-postgres master which includes the fix, and still get the error.

[sfackler]

@paul I haven't made any change to the behavior yet - I just added support so that you can tell that a type is a domain. There's a test here showing the current behavior: https://github.com/sfackler/rust-postgres/blob/master/tests/types/mod.rs#L239.

[sfackler]

I created a library which will allow you to #[derive(FromSql, ToSql)] for domains along with some other types: https://github.com/sfackler/rust-postgres-derive

[sfackler]

The current semantics are fixed for the time being, so I'm going to close this.