Type Overrides in Column Names and Bind Arguments

[abonander]

BASED ON #399

closes #339

TODO:

• test bind argument overrides
• test column name overrides for MySQL, SQLite
• document column type overrides
• document bind arg type overrides
• implement, doc and test foo as "foo?" override (forgot this one)

[phated]

Testing this out in my project and it seems to be working pretty well! The only trouble I ran into was a nullable bind param. I'm not sure if that falls into the WIP nullable override.

If I do my_val as Option<MyType>, it seems to wrap the input in another Option and the error says it expected Option<Option<MyType>>

Edit: Oh, the other issue is arrays of custom types. I expected my_column AS "my_column: Vec<MyType>" to work in Postgres.

[abonander]

Can you give the error message you're getting in the second case?

[phated]

@abonander for my_column AS "my_column: Vec<MyType>", I get the message: error: encountered unexpected or invalid data: user-defined array types are unsupported

[abonander]

Hmm, that's coming from the protocol layer in core:

sqlx/sqlx-core/src/postgres/connection/describe.rs

Line 137 in 8a83c98

b'A' => Err(err_protocol!("user-defined array types are unsupported")),

Unfortunately there's no comment here explaining why they're currently unsupported cough@mehcodecough

[abonander]

I think we just never really discussed how to represent arrays of user-defined types in the output of Describe. I think there's some refactoring necessary for PgTypeInfo probably, maybe elem_type() -> Option<PgTypeInfo> and array_type() -> Option<PgTypeInfo> getters.

[mehcode]

Custom types in arrays is orthogonal to this pull request. The complicated part is how to do this with PgTypeInfo.

We currently have PgTypeInfo::with_name("my_custom_type"). That lazily resolves to the OID for the scalar type. Arrays are special in postgres in that they don't have a defined name (I mean they do have a name but its not something we or the user will know, it normally is a single-underscore prefix of the scalar name but that isn't guaranteed).

We need like PgTypeInfo::array_with_name("my_custom_type") or PgTypeInfo::array(PgTypeInfo::with_name("my_custom_type")) that would resolve the array type OID of the given scalar type name.

Once we figure out how we're doing that, actually making this work is a 5 line addition to the Type derive.

[phated]

While poking at this today, I noticed that Postgres provides another column in the types table called typelem which is the OID of the inner element of the array. Not sure if that could help.

[abonander]

@phated sorry try your my_val as Option<MyType> test now.

[phated]

@abonander Sorry for the delay here. I was just able to test my_val as Option<MyType> and it works great! Did y'all want me to open an issue about user-defined array types?

[joaquindk]

Hi there, is there a way to use the query_as! macro to select all columns on a table and only override the type of 1 of them without having to list all of the columns?

Ie. I want to avoid having to do SELECT id as "id?", first_name, last_name, email from users WHERE id = $1 and instead do something like SELECT * WITH id as "id?" from users WHERE id = $1