Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make PgTypeInfo publicly-constructible to support custom types #58

Closed
jplatte opened this issue Jan 15, 2020 · 7 comments
Closed

Make PgTypeInfo publicly-constructible to support custom types #58

jplatte opened this issue Jan 15, 2020 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@jplatte
Copy link
Contributor

jplatte commented Jan 15, 2020

In PostgreSQL, custom types can be created with CREATE TYPE (e.g. enums). To interface with such types using sqlx, one would have to (amongst other things) implement HasSqlType<CustomType> for Postgres, which in turn requires being able to construct a PgTypeInfo. PgTypeInfo currently doesn't have a public constructor or all-public fields though.

@mehcode
Copy link
Member

mehcode commented Jan 17, 2020

After some internal discussion we've decided to add something like:

PgTypeInfo::with_name("dsflsdjfl")
PgTypeInfo::with_oid(201012)

with_name will be added a bit later but will involve querying postgres at runtime for the OID ( and caching it ).

@mehcode mehcode added the enhancement New feature or request label Jan 17, 2020
@jplatte
Copy link
Contributor Author

jplatte commented Jan 17, 2020

will involve querying postgres at runtime for the OID

So the PgTypeInfo will basically become statful for this case? As in, you first construct it as "an unknown type with the name x" and that later becomes "the type with the OID _"?

Or will HasSqlType::type_info be changed so a database connection is available?

@mehcode
Copy link
Member

mehcode commented Jan 17, 2020

In short, no. It'll probably internally be an enum between "Name" and "OID".

  • The Arguments type (already) builds an array of TypeInfo objects during the .bind, .bind process.

  • Just before running PREPARE ... for the statement we can query for the OID ( of any custom types ) and add it to a typename to OID cache on PgConnection.

@abonander
Copy link
Collaborator

  • and then when decoding the DataRow for Postgres we can look up in that cache to get the original type name again, which we can check in RowIndex::try_get().

@jplatte
Copy link
Contributor Author

jplatte commented Jan 17, 2020

Ah, that makes sense. Thanks for all the details. Would you be interested in a PR?

@abonander
Copy link
Collaborator

abonander commented Jan 17, 2020

Adding PgTypeInfo::with_oid()? Please do! The rest of the stuff is gonna be a bit involved.

Keep in mind that the reason that we want to support types by name is that the type OID isn't going to be stable across databases for custom types, if stuff got added in a different order or it's a newer version with more types. However, OIDs should be sufficient for tinkering with custom types against a single database.

@mehcode mehcode self-assigned this Mar 26, 2020
@mehcode mehcode mentioned this issue Mar 26, 2020
13 tasks
@mehcode
Copy link
Member

mehcode commented Mar 27, 2020

Added PgTypeInfo::with_name on master

@mehcode mehcode closed this as completed Mar 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants