Multi column distinct_on for Postgresql

.github/ISSUE_TEMPLATE/bug_report.md

@@ -45,13 +45,13 @@ If you want to report a bug, we added some points below which help us track down
 Please include as much of your codebase as needed to reproduce the error.  If the relevant files are large, please consider linking to a public repository or a [Gist](https://gist.github.com/). This includes normally the following parts:
 
 * The exact code where your hit the problem
-* Relevant parts your schema, so any `table!` macro calls required for the
+* Relevant parts your schema, so any `table!` macro calls required for
 * Any other type definitions involved in the code, which produces your problem
 -->
 
 ## Checklist
 
-- [ ] I have already looked over the [issue tracker](https://github.com/diesel-rs/diesel/issues)  and the [disussion forum](https://github.com/diesel-rs/diesel/discussions)  for similar possible closed issues.
+- [ ] I have already looked over the [issue tracker](https://github.com/diesel-rs/diesel/issues) and the [discussion forum](https://github.com/diesel-rs/diesel/discussions) for similar possible closed issues.
 <!--
 If you are unsure if your issue is a duplicate of an existing issue please link the issue in question here
 --> 

CHANGELOG.md

@@ -24,6 +24,8 @@ Increasing the minimal supported Rust version will always be coupled at least wi
   on the difference between your database and the provided `schema.rs` file
 * Add a `ON CONFLICT (...) DO UPDATE ... [WHERE ...]` conditional clause support for PostgreSQL.
 * Add support for MySQL's `ON DUPLICATE KEY DO UPDATE` syntax through the existing upsert functions.
+* Add ability to define multiple columns in a single `distinct_on` for PostgreSQL,
+  like: `.distinct_on((column_a, column_b))`.
 * Support for `libsqlite3-sys` 0.26
 
 ## [diesel_derives 2.0.2] 2023-03-13 
@@ -334,7 +336,7 @@ queries or set `PIPES_AS_CONCAT` manually.
 
 ### Fixed
 
-* Fixed a incompatibly between `diesel` and `diesel_migrations` when building both crates with cargos new `resolver = "2"` enabled. This change ensures compatibility with the upcomming 2021 rust edition.
+* Fixed a incompatibly between `diesel` and `diesel_migrations` when building both crates with cargos new `resolver = "2"` enabled. This change ensures compatibility with the upcoming 2021 rust edition.
 
 ## [1.4.7] - 2021-06-08
 
@@ -368,7 +370,7 @@ queries or set `PIPES_AS_CONCAT` manually.
 ### Fixed
 
 * Update several dependencies
-* Fixed a bug with printing embeded migrations
+* Fixed a bug with printing embedded migrations
 
 ## [1.4.3] - 2019-10-11
 

diesel/src/backend.rs

@@ -35,23 +35,23 @@ pub(crate) use self::private::{DieselReserveSpecialization, TrustedBackend};
 /// connection is implemented.
 /// For example, the `Pg` backend does not assume that `libpq` is being used.
 /// Implementations of this trait can and should care about details of the wire
-/// protocol used to communicated with the database.
+/// protocol used to communicate with the database.
 ///
 /// Implementing support for a new backend is a complex topic and depends on the
-/// details how the newly implemented backend may communicate with diesel. As of this
+/// details how the newly implemented backend may communicate with diesel. As of this,
 /// we cannot provide concrete examples here and only present a general outline of
 /// the required steps. Existing backend implementations provide a good starting point
-/// to see how certain things are solve for other backend implementations.
+/// to see how certain things are solved for other backend implementations.
 ///
 /// Types implementing `Backend` should generally be zero sized structs.
 ///
-/// To implement the `Backend` trait you need to:
+/// To implement the `Backend` trait, you need to:
 ///
 /// * Specify how a query should be build from string parts by providing a [`QueryBuilder`]
 /// matching your backend
 /// * Specify the bind value format used by your database connection library by providing
 /// a [`BindCollector`](crate::query_builder::bind_collector::BindCollector) matching your backend
-/// * Specify  how values are receive from the database by providing a corresponding raw value
+/// * Specify how values are received from the database by providing a corresponding raw value
 /// definition
 /// * Control sql dialect specific parts of diesels query dsl implementation by providing a
 /// matching [`SqlDialect`] implementation
@@ -127,7 +127,7 @@ pub type BindCollector<'a, DB> = <DB as Backend>::BindCollector<'a>;
 ///
 /// Accessing anything from this trait is considered to be part of the
 /// public API. Implementing this trait is not considered to be part of
-/// diesels public API, as future versions of diesel may add additional
+/// diesel's public API, as future versions of diesel may add additional
 /// associated constants here.
 ///
 /// Each associated type is used to configure the behaviour
@@ -141,9 +141,9 @@ pub type BindCollector<'a, DB> = <DB as Backend>::BindCollector<'a>;
     doc = "See the [`sql_dialect`] module for options provided by diesel out of the box."
 )]
 pub trait SqlDialect: self::private::TrustedBackend {
-    /// Configures how this backends supports `RETURNING` clauses
+    /// Configures how this backend supports `RETURNING` clauses
     ///
-    /// This allows backends to opt in  `RETURNING` clause support and to
+    /// This allows backends to opt in `RETURNING` clause support and to
     /// provide a custom [`QueryFragment`](crate::query_builder::QueryFragment)
     #[cfg_attr(
         feature = "i-implement-a-third-party-backend-and-opt-into-breaking-changes",
@@ -365,7 +365,7 @@ pub(crate) mod sql_dialect {
     pub mod returning_clause {
         /// A marker trait indicating if a `RETURNING` clause is supported or not
         ///
-        /// If you use custom type to specify specialized support for `RETURNING` clauses
+        /// If you use a custom type to specify specialized support for `RETURNING` clauses
         /// implementing this trait opts in supporting `RETURNING` clause syntax
         pub trait SupportsReturningClause {}
 
@@ -403,7 +403,7 @@ pub(crate) mod sql_dialect {
         pub struct IsoSqlDefaultKeyword;
 
         /// Indicates that a backend does not support `DEFAULT` value
-        /// expressions0for `INSERT INTO` statements
+        /// expressions for `INSERT INTO` statements
         #[derive(Debug, Copy, Clone)]
         pub struct DoesNotSupportDefaultKeyword;
 
@@ -423,7 +423,7 @@ pub(crate) mod sql_dialect {
         /// Indicates that this backend does not support batch
         /// insert statements.
         /// In this case diesel will emulate batch insert support
-        /// by inserting each row on it's own
+        /// by inserting each row on its own
         #[derive(Debug, Copy, Clone)]
         pub struct DoesNotSupportBatchInsert;
 
@@ -529,7 +529,7 @@ pub(crate) mod private {
     /// suggests adding this a bound to a type implementing `Backend`
     /// consider adding the following bound instead
     /// `YourQueryType: QueryFragment<DB>` (the concrete bound
-    /// is likely mentioned by rustc as part of a `note: …`
+    /// is likely mentioned by rustc as part of a `note: …`)
     ///
     /// For any user implementing a custom backend: You likely want to implement
     /// this trait for your custom backend type to opt in the existing [`QueryFragment`] impls in diesel.
@@ -544,7 +544,7 @@ pub(crate) mod private {
     )]
     pub trait DieselReserveSpecialization {}
 
-    /// This trait just indicates that noone implements
+    /// This trait just indicates that none implements
     /// [`SqlDialect`](super::SqlDialect) without enabling the
     /// `i-implement-a-third-party-backend-and-opt-into-breaking-changes`
     /// feature flag.

diesel/src/connection/mod.rs

@@ -96,7 +96,7 @@ pub type LoadRowIter<'conn, 'query, C, DB, B = DefaultLoadingMode> =
 ///
 /// Implementing a new connection based on an existing backend can enable the usage of
 /// other methods to connect to the database. One example here would be to replace
-/// the offical diesel provided connection implementations with an implementation
+/// the official diesel provided connection implementations with an implementation
 /// based on a pure rust connection crate.
 ///
 /// **It's important to use prepared statements to implement the following methods:**
@@ -131,7 +131,7 @@ pub type LoadRowIter<'conn, 'query, C, DB, B = DefaultLoadingMode> =
 /// * A field type that describes a database field value.
 ///   This type needs to implement [`Field`](crate::row::Field)
 /// * A connection type that wraps the connection +
-///   the nessesary state managment.
+///   the necessary state management.
 /// * Maybe a [`TransactionManager`] implementation matching
 ///  the interface provided by the database connection crate.
 ///  Otherwise the implementation used by the corresponding
@@ -163,7 +163,7 @@ pub type LoadRowIter<'conn, 'query, C, DB, B = DefaultLoadingMode> =
 /// As implementations differ significantly between the supported backends
 /// we cannot give a one for all description here. Generally it's likely a
 /// good idea to follow the implementation of the corresponding connection
-/// in diesel at a heigh level to gain some idea how to implement your
+/// in diesel at a high level to gain some idea how to implement your
 /// custom implementation.
 ///
 /// ## Implement support for an unsupported database system
@@ -309,7 +309,7 @@ where
         };
         Self::TransactionManager::begin_transaction(self)?;
         // set the test transaction flag
-        // to pervent that this connection gets droped in connection pools
+        // to prevent that this connection gets dropped in connection pools
         // Tests commonly set the poolsize to 1 and use `begin_test_transaction`
         // to prevent modifications to the schema
         Self::TransactionManager::transaction_manager_status_mut(self).set_test_transaction_flag();
@@ -386,7 +386,7 @@ where
 /// The specific part of a [`Connection`] which actually loads data from the database
 ///
 /// This is a separate trait to allow connection implementations to specify
-/// different loading modes via the generic paramater.
+/// different loading modes via the generic parameter.
 pub trait LoadConnection<B = DefaultLoadingMode>: Connection {
     /// The cursor type returned by [`LoadConnection::load`]
     ///

diesel/src/connection/statement_cache.rs

@@ -117,7 +117,7 @@ pub struct StatementCache<DB: Backend, Statement> {
 ///
 /// This information can be used by the connection implementation
 /// to signal this fact to the database while actually
-/// perparing the statement
+/// preparing the statement
 #[derive(Debug, Clone, Copy)]
 #[cfg_attr(
     doc_cfg,

diesel/src/deserialize.rs

@@ -488,7 +488,7 @@ where
     }
 }
 
-/// A helper trait to deserialize a statically sized row into an tuple
+/// A helper trait to deserialize a statically sized row into a tuple
 ///
 /// **If you see an error message mentioning this trait you are likely trying to
 /// map the result of a query to a struct with mismatching field types. Recheck
@@ -526,7 +526,7 @@ where
     T::Row: FromStaticSqlRow<ST, DB>,
 {
     // This inline(always) attribute is here as benchmarks have shown
-    // a up to 5% reduction in instruction count of having it here
+    // up to 5% reduction in instruction count of having it here
     //
     // A plain inline attribute does not show similar improvements
     #[inline(always)]

diesel/src/expression/array_comparison.rs

@@ -1,5 +1,5 @@
 //! This module contains the query dsl node definitions
-//! for array comparision operations like `IN` and `NOT IN`
+//! for array comparison operations like `IN` and `NOT IN`
 
 use crate::backend::sql_dialect;
 use crate::backend::Backend;
@@ -25,7 +25,7 @@ use std::marker::PhantomData;
 /// Third party backend can customize the [`QueryFragment`]
 /// implementation of this query dsl node via
 /// [`SqlDialect::ArrayComparison`]. A customized implementation
-/// is expected to provide the same sematics as a ANSI SQL
+/// is expected to provide the same semantics as an ANSI SQL
 /// `IN` expression.
 ///
 /// The postgres backend provided a specialized implementation
@@ -45,7 +45,7 @@ pub struct In<T, U> {
 /// Third party backend can customize the [`QueryFragment`]
 /// implementation of this query dsl node via
 /// [`SqlDialect::ArrayComparison`]. A customized implementation
-/// is expected to provide the same sematics as a ANSI SQL
+/// is expected to provide the same semantics as an ANSI SQL
 /// `NOT IN` expression.0
 ///
 /// The postgres backend provided a specialized implementation
@@ -154,13 +154,13 @@ impl_selectable_expression!(NotIn<T, U>);
 /// This trait describes how a type is transformed to the
 /// `IN (values)` value expression
 ///
-/// Diesel provided several implemenations here:
+/// Diesel provided several implementations here:
 ///
 ///  - An implementation for any [`Iterator`] over values
 ///  that implement [`AsExpression<ST>`] for the corresponding
 ///  sql type ST. The corresponding values clause will contain
 ///  bind statements for each individual value.
-///  - An implementation for select statements, that return
+///  - An implementation for select statements, that returns
 ///  a single field. The corresponding values clause will contain
 ///  the sub query.
 ///
@@ -196,7 +196,7 @@ where
 }
 
 /// A helper trait to check if the values clause of
-/// a [`In`] or [`NotIn`] query dsl node is empty or not
+/// an [`In`] or [`NotIn`] query dsl node is empty or not
 pub trait MaybeEmpty {
     /// Returns `true` if self represents an empty collection
     /// Otherwise `false` is returned.
@@ -243,7 +243,7 @@ where
     }
 }
 
-/// Query dsl node for a `IN (values)` clause containing
+/// Query dsl node for an `IN (values)` clause containing
 /// a variable number of bind values.
 ///
 /// Third party backend can customize the [`QueryFragment`]

diesel/src/expression/exists.rs

@@ -43,7 +43,7 @@ pub fn exists<T>(query: T) -> exists<T> {
 /// Third party backend can customize the [`QueryFragment`]
 /// implementation of this query dsl node via
 /// [`SqlDialect::ExistsSyntax`]. A customized implementation
-/// is expected to provide the same sematics as a ANSI SQL
+/// is expected to provide the same semantics as an ANSI SQL
 /// `EXIST (subselect)` expression.
 #[derive(Clone, Copy, QueryId, Debug)]
 #[non_exhaustive]

diesel/src/expression/mod.rs

@@ -755,7 +755,7 @@ pub mod is_aggregate {
 }
 
 #[cfg(feature = "unstable")]
-// this needs to be a seperate module for the reasons given in
+// this needs to be a separate module for the reasons given in
 // https://github.com/rust-lang/rust/issues/65860
 mod unstable;
 

diesel/src/lib.rs

@@ -155,7 +155,7 @@
 //!
 //! - `sqlite`: This feature enables the diesel sqlite backend. Enabling this feature requires per default
 //! a compatible copy of `libsqlite3` for your target architecture. Alternatively, you can add `libsqlite3-sys`
-//! with the `bundled` feature as a dependecy to your crate so SQLite will be bundled:
+//! with the `bundled` feature as a dependency to your crate so SQLite will be bundled:
 //! ```toml
 //! [dependencies]
 //! libsqlite3-sys = { version = "0.25.2", features = ["bundled"] }
@@ -204,7 +204,7 @@
 //! - `numeric`: This feature flag enables support for (de)serializing numeric values from the database using types
 //! provided by `bigdecimal`
 //! - `r2d2`: This feature flag enables support for the `r2d2` connection pool implementation.
-//! - `extras`: This feature enables the feature flaged support for any third party crate. This implies the
+//! - `extras`: This feature enables the feature flagged support for any third party crate. This implies the
 //! following feature flags: `serde_json`, `chrono`, `uuid`, `network-address`, `numeric`, `r2d2`
 //! - `with-deprecated`: This feature enables items marked as `#[deprecated]`. It is enabled by default.
 //! disabling this feature explicitly opts out diesels stability guarantee.

diesel/src/macros/mod.rs

@@ -68,7 +68,7 @@ pub use diesel_derives::table_proc as table;
 ///
 /// * `child_table` is the Table with the Foreign key.
 ///
-/// So given the Table decaration from [Associations docs](crate::associations)
+/// So given the Table declaration from [Associations docs](crate::associations)
 ///
 /// * The parent table would be `User`
 /// * The child table would be `Post`
@@ -249,7 +249,7 @@ macro_rules! __diesel_internal_backend_specific_allow_tables_to_appear_in_same_q
 #[macro_export]
 #[cfg(not(feature = "postgres_backend"))]
 macro_rules! __diesel_internal_backend_specific_allow_tables_to_appear_in_same_query {
-    ($left:ident, $rigth:ident) => {};
+    ($left:ident, $right:ident) => {};
 }
 
 #[doc(hidden)]
@@ -633,7 +633,7 @@ mod tests {
             }
         }
 
-        // allow using table::collumn
+        // allow using table::column
         allow_columns_to_appear_in_same_group_by_clause!(a::b, b::a, a::d,);
 
         // allow using full paths

diesel/src/migration/mod.rs

@@ -136,7 +136,7 @@ pub trait MigrationMetadata {
 /// to receive a number of migrations from.
 pub trait MigrationSource<DB: Backend> {
     /// Get a list of migrations associated with this
-    /// migration soucre.
+    /// migration source.
     fn migrations(&self) -> Result<Vec<Box<dyn Migration<DB>>>>;
 }