You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A sizeable amount of sysadmins prefer PostgreSQL over MySQL/MariaDB. As such, Postgres should be supported in symfonia as well. This could be accommodated for by using the sqlx::Any trait instead of sqlx::MySql throughout the codebase.
Changes are being made in chorus to support sqlx::Any, as well as updating sqlx to version 0.8.0.
The text was updated successfully, but these errors were encountered:
Going forward, the supported Database flavor will be PostgreSQL. Supporting many different SQL flavors is nice, but taking full advantage of the features one SQL flavor has to offer is better, in my opinion. "A Jack of all trades is a master of none", and so on.
Issues that remain here are:
Removing nested structs which are Json<T> in favor of foreign keys/breaking out everything into its own tables, where it makes sense.
Related to above: Rewrite CREATE TABLE statements as well as query!() calls to query nested struct tables as well, where it makes sense.
Support unsigned integers in PostgreSQL by either using #[sqlx(try_from = sqlx::types::Decimal)] or by creating wrapper types which translate Rusts unsigned integers into Postgres' DECIMAL/NUMERIC types while guaranteeing that the DECKMAL/NUMERIC loaded from a table is not out of bounds for the selected integer size
bitfl0wer
changed the title
Support PostgreSQL, use sqlx::Any if possible
Support PostgreSQL
Aug 14, 2024
A sizeable amount of sysadmins prefer PostgreSQL over MySQL/MariaDB. As such, Postgres should be supported in symfonia as well. This could be accommodated for by using the
sqlx::Any
trait instead ofsqlx::MySql
throughout the codebase.Changes are being made in chorus to support sqlx::Any, as well as updating sqlx to version 0.8.0.
The text was updated successfully, but these errors were encountered: