SQLx 0.6.0 Release Tracking Issue

[abonander]

Our SQLx-Next initiative (#1163) has been pushed back to 0.7.0 as we wait for Generic Associated Types to be stabilized, as GATs will make it possible to do a lot of cleanup in the API.

In the meantime, we've decided to backport a handful of features we're really excited for, as well as merge in some feature work from contributors that has been in the pipeline for a while.

Backport

• Generalized Query Placeholders ([Next] [Feature] Generalized query placeholders (including support for expanding arrays into multiple placeholders) #875)

Database-agnostic syntax for bind parameters, providing named parameters and comma-expansion for arrays.

Additionally, the query!() family of macros will support implicit bindings from scope like that proposed for format_args! in RFC #2795:

let bars = vec!["bar1", "bar2", "bar3"];
let baz = 1i32;

sqlx::query!("UPDATE foo SET baz = {baz} WHERE bar IN ({bars+})")
    .execute(&mut conn)
    .await?;

• Binding named parameters at runtime: ([Proposal] Support named bind parameters #199)

sqlx::query("INSERT INTO foo(bar, baz) VALUES (%bar, %baz)")
    .bind_as("bar", &bar)
    .bind_as("baz", &baz)

Contributions

• Switch to one-file-per-query for query!() offline mode (Move to one-file-per-query for sqlx-cli prepare #570)

Eliminates dealing with constant merge conflicts in sqlx-data.json with multiple people contributing to the same repository.

The macros will be able to save their data automatically which means you shouldn't need to remember cargo sqlx prepare as long as you've built the project at least once after adding or changing a macro definition.

Compiling in offline mode should be faster as projects with many query!() invocations won't need to repeatedly re-parse the same gigantic file. This would be further improved by using a binary file format supporting zero-copy parsing, like Cap'N'Proto.

• (released 0.5.9) implement support for Postgres' COPY [FROM | TO] STDIN (Add support for COPY ... FROM STDIN and COPY ... TO STDOUT statements in PostgreSQL #36)

The PR currently open (#1345) implements a basic low-level API which we can build on later with a strongly typed interface. Still, if you're looking to shove a giant CSV file into your database, this would be the place to start.

• Refactor Postgres array support (Rewrite Postgres array type handling #1385)

This should finally allow use of Vec<T> where T is a custom type with #[derive(sqlx::Type)].

• Support client certificates for TLS with Postgres (Postgres native tls does not support client certificates. #1162)

• (released 0.5.9) Support the immutable option for SQLite connections (Support the immutable option on SQLite connections #1289)

Misc

• Add support for time 0.3 (time dependency out of date #1277)

We will probably need to retain support for time 0.2 under a time-02 feature for at least the next couple releases.

[jplatte]

I'm excited for one-file-per-query, but I'm worried a bit that it will take a while before that will be done, and it's not clear how far along generalized query placeholders are either / how much work it is to backport them.

Can we have a 0.5.8 release first with a bunch of features that already have PRs? From a quick skim of the open PRs, these all seem to likely be mergeable as-is and non-breaking.

• Support the immutable option on SQLite connections #1289
• Finish support for Postgres COPY #1345
• feat: allow log level customization #1371
• Rewrite Postgres array type handling #1385
• Add executor trait "aliases" #1412
• Add more debugging info to unresolved type declaration panic #1416

[abonander]

I was planning on preparing a 0.5.8 release, though I initially wanted to keep it to just bugfixes as I was thinking of saving all the new features for the 0.6.0 release. It feels weird to me adding features in what is ostensibly a "patch" release. However, looking back through the changelog it appears we have added backwards-compatible features in 0.x.{y + 1} releases before so I'm fine with following that precedent.

Limiting the scope of 0.6.0 would also help get it out sooner, I suppose.

For generalized placeholders, I have the parsing implemented and was starting to integrate it into the Postgres and MySQL drivers on the next branch. That got a bit complicated with the whole "supporting both sync and async APIs" stuff so I think it's probably easier to backport it than integrate it into next.

Incidentally, your PR #1385 also effectively backports some of that work as I was also wanting to fix the trait impls for arrays. I would also like to add impl<T, const N: usize> Type for [T; N] but that would bump our MSRV (although officially we only support the latest stable Rust release, I think it would be inconsiderate to add a feature in 0.5.8 that requires a significantly newer Rust than 0.5.0 did) so I am probably going to save that for 0.6.0.

One file per query, I think I have a solid implementation plan for. I haven't looked at your old PR in too much depth but I may either reuse that or start from scratch, I'm not sure yet. I don't think it'll be all that much work, though.

[paolobarbolini]

Misc

* [ ]  Add support for `time 0.3` ([`time` dependency out of date #1277](https://github.com/launchbadge/sqlx/issues/1277))

There are a few more dependencies that need updating (see https://deps.rs/repo/github/launchbadge/sqlx).
I just sent a PR for ipnetwork (#1426) but I could also do a few more if I find the time to send them.

[ericsampson]

Hi Austin, it would be really useful for us to have the proposed #[sqlx(flatten)] FromRow attribute discussed in #156 as part of 0.6.0

I'm willing to give it a shot, if someone can provide some hints as to how I might approach the changes needed in derives/row.rs

[LukeMathWalker]

The features you are planning to backport will have a significant (positive!) impact on the ergonomics of sqlx - really looking forward to the release! 😁

[msdrigg]

I read some discussion earlier (#909) that mentioned efficient batch insertion as a point of interest for the 0.6 release. Is this still being considered? I might have missed it, but the tasks mentioned above didn't seem to cover it.

[abonander]

That is one of the main goals of #875 with the comma-expanded lists.

[paolobarbolini]

I'd love to also be able to get uuid v1 in when it's ready
https://github.com/uuid-rs/uuid/releases/tag/1.0.0-alpha.1

[mara-schulke]

I would love to see built in support for multiple schemas / schemas with names other than public, scoping types to schemas (#1171)