PostgreSQL UUID and JSONB support #3175
Conversation
| floating64(f64), | ||
| str(string), | ||
| binary(list<u8>), | ||
| date(tuple<s32, u8, u8>), // (year, month, day) |
There was a problem hiding this comment.
A tuple that needs a comment to explain its elements sounds like it wants to be a record . 🙂
There was a problem hiding this comment.
Yes: unfortunately, this was a mistake I made in v3 and I don't see value in changing it for v4 (yes, I know I am allowed to).
|
This PR now also adds the following types:
cc @tharpooljha There is still significant tidying to do: the new types make the Postgres code more complicated and easier to miss cases, and I had to add some helper types DIDN'T I THE ORPHAN RULE so it's pretty messy right now. I'll work on cleaning it up but anyway here it is so far. |
| array-str(list<option<string>>), | ||
| interval(interval), | ||
| db-null, | ||
| unsupported, |
There was a problem hiding this comment.
Would it make sense to have a e.g. raw(list<u8>)?
There was a problem hiding this comment.
Could you say more about what you're envisaging?
There was a problem hiding this comment.
Many postgres drivers provide some mechanism to extend their builtin types by converting to/from raw postgres values:
https://docs.rs/tokio-postgres/latest/tokio_postgres/types/trait.FromSql.html
https://pkg.go.dev/github.com/jackc/pgx/v4#hdr-Raw_Bytes_Mapping
https://www.psycopg.org/docs/advanced.html#type-casting-from-sql-to-python
There was a problem hiding this comment.
I guess raw would effectively be "other".
There was a problem hiding this comment.
Gotcha. Intercepting that may require us a bit more FromSql magic, I am not sure - we access values via get, which expects to return into a FromSql implementation that matches the column type, but maybe it will let us return anything into a Vec<u8>, or otherwise I can create a fake FromSql that accepts all types and just captures the raw bytes. I will take a look!
There was a problem hiding this comment.
Another thought: maybe this "other" variant could be a resource that additionally exposes type information about the value, like https://docs.rs/tokio-postgres/latest/tokio_postgres/types/struct.Type.html#method.oid
There was a problem hiding this comment.
Your lightest whim is my command (subject to applicable law and terms of service). I provisionally put the type name rather than the OID but if you have opinions then bring 'em on, I am utterly naive about this stuff.
There was a problem hiding this comment.
I don't really know how these are used in practice either, I'm just trying to save you from spending the rest of your days adding support for an neverending list of increasingly obscure data types. 😅
There was a problem hiding this comment.
Indeed - this has me thinking "what if I rewrote the whole interface to just tunnel EVERYTHING as blobs and let the guest language use whatever decoder is idiomatic" so your plan to free me from this rabbit hole may have backfired...
(Fear not. I do not intend to do this as part of this PR. Nor without a lot more research into the factoring of guest language DB libraries.)
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Signed-off-by: itowlson <[email protected]>
Fixes #1551. Fixes #2936.