2021-03-23 16:30:28 +03:00
|
|
|
cabal-version: 2.0
|
|
|
|
|
name: rel8
|
2024-03-19 17:48:26 +03:00
|
|
|
version: 1.5.0.0
|
2021-03-23 16:30:28 +03:00
|
|
|
synopsis: Hey! Hey! Can u rel8?
|
|
|
|
|
license: BSD3
|
|
|
|
|
license-file: LICENSE
|
|
|
|
|
author: Oliver Charles
|
|
|
|
|
maintainer: ollie@ocharles.org.uk
|
2021-06-19 18:46:23 +03:00
|
|
|
homepage: https://github.com/circuithub/rel8
|
|
|
|
|
bug-reports: https://github.com/circuithub/rel8/issues
|
2021-04-02 21:19:54 +03:00
|
|
|
build-type: Simple
|
2021-06-18 20:23:58 +03:00
|
|
|
extra-doc-files:
|
|
|
|
|
README.md
|
|
|
|
|
Changelog.md
|
2021-03-23 16:30:28 +03:00
|
|
|
|
2021-06-19 18:46:23 +03:00
|
|
|
source-repository head
|
|
|
|
|
type: git
|
|
|
|
|
location: https://github.com/circuithub/rel8
|
|
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
library
|
|
|
|
|
build-depends:
|
|
|
|
|
aeson
|
2023-09-27 13:39:04 +03:00
|
|
|
, attoparsec
|
2023-09-29 14:23:22 +03:00
|
|
|
, attoparsec-aeson
|
2024-02-21 15:40:30 +03:00
|
|
|
, base ^>= 4.16 || ^>= 4.17 || ^>= 4.18 || ^>= 4.19
|
2023-09-27 13:39:04 +03:00
|
|
|
, base16 >= 1.0
|
2023-07-07 20:48:21 +03:00
|
|
|
, base-compat ^>= 0.11 || ^>= 0.12 || ^>= 0.13
|
2021-07-15 16:59:58 +03:00
|
|
|
, bifunctors
|
2021-03-23 16:30:28 +03:00
|
|
|
, bytestring
|
|
|
|
|
, case-insensitive
|
2021-07-05 04:42:35 +03:00
|
|
|
, comonad
|
2021-03-23 16:30:28 +03:00
|
|
|
, contravariant
|
2023-09-27 13:39:04 +03:00
|
|
|
, data-textual
|
2023-04-14 12:56:03 +03:00
|
|
|
, hasql ^>= 1.6.1.2
|
|
|
|
|
, network-ip
|
2024-02-09 18:11:03 +03:00
|
|
|
, opaleye ^>= 0.10.2.1
|
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE (#85)
This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`).
Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert".
Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour.
Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables.
Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected.
In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
2021-07-15 02:30:59 +03:00
|
|
|
, pretty
|
2021-03-23 16:30:28 +03:00
|
|
|
, profunctors
|
2021-07-15 16:59:58 +03:00
|
|
|
, product-profunctors
|
2021-03-23 16:30:28 +03:00
|
|
|
, scientific
|
|
|
|
|
, semialign
|
|
|
|
|
, semigroupoids
|
|
|
|
|
, text
|
|
|
|
|
, these
|
|
|
|
|
, time
|
Statements overhaul (support for statement-level `WITH`) (#250)
The motivation behind this PR is to add support for PostreSQL's `WITH` syntax at the statement level, which gives the ability to, e.g., delete some rows from a table and then re-insert those deleted rows into another table, without any round-trips between the application and the database.
To support this, this PR introduces a new type called `Statement`, which represents a single PostgreSQL statement. It has a `Monad` instance which allows sub-statements (such as `DELETE` and `INSERT` statements) to be composed together and their results bound to values that can be referenced in subsequent sub-statements. These "compound" statements are then rendered as a `WITH` statement.
`select`, `insert`, `update` and `delete` have all been altered to produce the `Statement` type described above instead of the `Hasql.Statement` type.
Some changes were necessary to the `Returning` type. `Returning` previously bundled two different concepts together: whether or not to generate a `RETURNING` clause in the SQL for a manipulation statement, and how to decode the returned rows (if any). It was necessary to break these concepts apart because with `WITH` we need the ability to generate manipulation statements with `RETURNING` clauses that are never actually decoded at all (the results just get passed to the next statement without touching the application).
Now, the `Returning` type is only concerned with whether or not to generate a `RETURNING` clause, and the question of how to decode the returned the result of the statement is handled by the `run` functions. `run` converts a `Statement` into a runnable `Hasql.Statement`, decoding the result of the statement as a list of rows. The other variations, `run_`, `runN`, `run1`, `runMaybe` and `runVector` can be used when you want to decode as something other than a list of rows.
This also gains us support for decoding the result of a query directly to a `Vector` for the first time, which brings a performance improvement over lists for those who need it.
2023-07-07 13:29:15 +03:00
|
|
|
, transformers
|
2023-09-27 13:39:04 +03:00
|
|
|
, utf8-string
|
2021-03-23 16:30:28 +03:00
|
|
|
, uuid
|
Statements overhaul (support for statement-level `WITH`) (#250)
The motivation behind this PR is to add support for PostreSQL's `WITH` syntax at the statement level, which gives the ability to, e.g., delete some rows from a table and then re-insert those deleted rows into another table, without any round-trips between the application and the database.
To support this, this PR introduces a new type called `Statement`, which represents a single PostgreSQL statement. It has a `Monad` instance which allows sub-statements (such as `DELETE` and `INSERT` statements) to be composed together and their results bound to values that can be referenced in subsequent sub-statements. These "compound" statements are then rendered as a `WITH` statement.
`select`, `insert`, `update` and `delete` have all been altered to produce the `Statement` type described above instead of the `Hasql.Statement` type.
Some changes were necessary to the `Returning` type. `Returning` previously bundled two different concepts together: whether or not to generate a `RETURNING` clause in the SQL for a manipulation statement, and how to decode the returned rows (if any). It was necessary to break these concepts apart because with `WITH` we need the ability to generate manipulation statements with `RETURNING` clauses that are never actually decoded at all (the results just get passed to the next statement without touching the application).
Now, the `Returning` type is only concerned with whether or not to generate a `RETURNING` clause, and the question of how to decode the returned the result of the statement is handled by the `run` functions. `run` converts a `Statement` into a runnable `Hasql.Statement`, decoding the result of the statement as a list of rows. The other variations, `run_`, `runN`, `run1`, `runMaybe` and `runVector` can be used when you want to decode as something other than a list of rows.
This also gains us support for decoding the result of a query directly to a `Vector` for the first time, which brings a performance improvement over lists for those who need it.
2023-07-07 13:29:15 +03:00
|
|
|
, vector
|
2023-09-27 13:39:04 +03:00
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
default-language:
|
|
|
|
|
Haskell2010
|
|
|
|
|
ghc-options:
|
2021-07-06 14:36:11 +03:00
|
|
|
-Werror=missing-methods -Werror=incomplete-patterns -Werror=missing-fields
|
2021-03-23 16:30:28 +03:00
|
|
|
-Weverything -Wno-unsafe -Wno-safe -Wno-missing-safe-haskell-mode
|
|
|
|
|
-Wno-missing-import-lists -Wno-prepositive-qualified-module
|
|
|
|
|
-Wno-monomorphism-restriction
|
2021-06-18 11:46:44 +03:00
|
|
|
-Wno-missing-local-signatures
|
2022-01-25 15:01:14 +03:00
|
|
|
-Wno-missing-kind-signatures
|
2021-03-23 16:30:28 +03:00
|
|
|
hs-source-dirs:
|
|
|
|
|
src
|
|
|
|
|
exposed-modules:
|
2021-03-23 17:33:23 +03:00
|
|
|
Rel8
|
2023-10-20 14:17:36 +03:00
|
|
|
Rel8.Array
|
2021-03-26 05:25:47 +03:00
|
|
|
Rel8.Expr.Num
|
2021-03-24 18:37:28 +03:00
|
|
|
Rel8.Expr.Text
|
|
|
|
|
Rel8.Expr.Time
|
2021-07-15 16:59:58 +03:00
|
|
|
Rel8.Tabulate
|
2021-03-26 00:57:26 +03:00
|
|
|
|
2021-03-24 16:01:56 +03:00
|
|
|
other-modules:
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Aggregate
|
Aggregation overhaul — return to Profunctor and semi-aggregations (#235)
This PR makes a number of changes to how aggregation works in Rel8.
The biggest change is that we drop the `Aggregate` context and we return to the `Profunctor`-based `Aggregator` that Opaleye uses (as in #37). While working with `Profunctor`s is more awkward for many common use-cases, it's ultimately more powerful. The big thing it gives you that we don't currently have is the ability to "post-map" on the result of an aggregation function. Pretend for a moment that Postgres does not have the `avg` function built-in. With the previous Rel8, there is no way to directly write `sum(x) / count(x)`. The best you could do would something like:
```haskell
fmap (\(total, size) -> total / fromIntegral size) $ aggregate $ do
foo <- each fooSchema
pure (sum foo.x, count foo.x)
```
The key thing is that the mapping can only happen after `aggregate` is called. Whereas with the `Profunctor`-based `Aggregator` this is just `(/) <$> sum <*> fmap fromIntegral count`. This isn't too bad if the only thing you want to do is computing the average, but if you're doing a complicated aggregation with several things happening at once then you might need to do several unrelated post-processings after the `aggregate`. We really want a way to bundle up the postmapping with the aggregation itself and have that as a singular composable unit. Another example is the `listAggExpr` function. The only reason Rel8 exports this is because it can't be directly expressed in terms of `listAgg`. With the `Profunctor`-based `Aggregator` it can be, it's just `(id $*) <$> listAgg`, it no longer needs to be a special case.
The original attempt in #37 recognised that it can be awkward to have to write `lmap (.x) sum`, so instead of sum having the type signature `Aggregator (Expr a) (Expr a)`, it had the type signature `(i -> Expr a) -> Aggregator i (Expr a)`, so that you wouldn't have to use `lmap`, you could just type `sum (.x)`. However, there are many ways to compose `Aggregator`s — for example, if you wanted to use combinators from `product-profunctor` to combine aggregators, then you'd rather type `sum ***! count` than `sum id ***! count id`. So in this PR we keep the type of `sum` as `Aggregator (Expr a) (Expr a)`, but we also export `sumOn`, which has the bundled `lmap`.
The other major change is that this PR introduces two forms of aggregation — "semi"-aggregation and "full"-aggregation. Up until now, all aggregation in Rel8 was "semi"-aggregation, but "full"-aggregation feels a bit more natural and Haskelly.
Up until now, the `aggrgegate` combinator in Rel8 would return zero rows if given a query that itself returned zero rows, even if the aggregation functions that comprised it had identity values. So it was very common to see code like `fmap (fromMaybeTable 0) $ optional $ aggregate $ sum <$> _`. Again, we "know" that `0` is the identity value for `sum` and we really want some way to bundle those together and to say "return the identity value if there are zero rows". Rel8 now has this ability — it has both `Aggregator` and `Aggregator1`, with the former having identity values and the latter not. The `aggregate` function now takes an `Aggregator` and returns the identity value when encountering zero rows, whereas the `aggregate1` function takes an `Aggregator1` and behaves as before. `count`, `sum`, `and`, `or`, `listAgg` are `Aggregator`s (with the identity values `0`, `0`, `true`, `false` and `listTable []` respectively) and `groupBy`, `max` and `min` are `Aggregator1`s.
This also means that `many` is now just `aggregate listAgg` instead of `fmap (fromMaybeTable (listTable [])) . optional . aggregate . fmap listAgg`.
It should also be noted that these functions are actually polymorphic — `sum` will actually give you an `Aggregator'` that can be used as either `Aggregator` or `Aggregator1` without needing to explicitly convert between them. Similarly `aggregate1` can take either an `Aggegator` or an `Aggregator1` (though it won't use the identity value of the former).
Aggregation in Rel8 now supports more of the features of PostgresSQL supports. Three new combinators are introduced — `distinctAggregate`, `filterWhere` and `orderAggregateBy`.
Opaleye itself already supported `distinctAggregate` and indeed we used this to implement `countDistinct` as a special case, but we now support using `DISTINCT` on arbitrary aggregation functions.
`filterWhere` is new to both Rel8 and Opaleye. It corresponds to PostgreSQL's `FILTER (WHERE ...)` syntax in aggregations. It also uses the identity value of an `Aggregator` in the case where the given predicate returns zero rows. There is also `filterWhereOptional` which can be used with `Aggregator1`s.
`orderAggregateBy` allows the values within an aggregation to be ordered using a given ordering, mainly non-commutative aggregation functions like `listAgg`.
2023-06-18 23:05:00 +03:00
|
|
|
Rel8.Aggregate.Fold
|
2024-01-09 04:28:04 +03:00
|
|
|
Rel8.Aggregate.Function
|
2021-03-23 16:30:28 +03:00
|
|
|
|
2021-04-30 18:48:55 +03:00
|
|
|
Rel8.Column
|
2021-05-01 12:21:57 +03:00
|
|
|
Rel8.Column.ADT
|
2021-04-30 18:48:55 +03:00
|
|
|
Rel8.Column.Either
|
2021-04-30 20:13:06 +03:00
|
|
|
Rel8.Column.Lift
|
2021-04-30 18:48:55 +03:00
|
|
|
Rel8.Column.List
|
|
|
|
|
Rel8.Column.Maybe
|
|
|
|
|
Rel8.Column.NonEmpty
|
2022-05-20 14:34:45 +03:00
|
|
|
Rel8.Column.Null
|
2021-04-30 18:48:55 +03:00
|
|
|
Rel8.Column.These
|
|
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Expr
|
|
|
|
|
Rel8.Expr.Aggregate
|
|
|
|
|
Rel8.Expr.Array
|
|
|
|
|
Rel8.Expr.Bool
|
2021-06-29 21:45:27 +03:00
|
|
|
Rel8.Expr.Default
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Expr.Eq
|
|
|
|
|
Rel8.Expr.Function
|
2023-06-24 13:27:56 +03:00
|
|
|
Rel8.Expr.List
|
|
|
|
|
Rel8.Expr.NonEmpty
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Expr.Null
|
|
|
|
|
Rel8.Expr.Opaleye
|
|
|
|
|
Rel8.Expr.Ord
|
|
|
|
|
Rel8.Expr.Order
|
2023-09-27 13:41:27 +03:00
|
|
|
Rel8.Expr.Read
|
2021-06-17 15:30:37 +03:00
|
|
|
Rel8.Expr.Sequence
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Expr.Serialize
|
2023-09-27 13:41:27 +03:00
|
|
|
Rel8.Expr.Show
|
2022-10-14 04:06:07 +03:00
|
|
|
Rel8.Expr.Window
|
2021-03-23 16:30:28 +03:00
|
|
|
|
2021-03-24 17:25:14 +03:00
|
|
|
Rel8.FCF
|
|
|
|
|
|
2021-04-30 17:04:48 +03:00
|
|
|
Rel8.Kind.Algebra
|
2021-04-27 16:40:10 +03:00
|
|
|
Rel8.Kind.Context
|
2021-03-23 16:30:28 +03:00
|
|
|
|
2021-05-05 03:27:36 +03:00
|
|
|
Rel8.Generic.Construction
|
2021-05-04 07:22:20 +03:00
|
|
|
Rel8.Generic.Construction.ADT
|
|
|
|
|
Rel8.Generic.Construction.Record
|
2021-04-27 00:26:13 +03:00
|
|
|
Rel8.Generic.Map
|
2021-04-18 02:52:15 +03:00
|
|
|
Rel8.Generic.Record
|
2021-04-30 17:04:48 +03:00
|
|
|
Rel8.Generic.Rel8able
|
2021-04-27 00:24:52 +03:00
|
|
|
Rel8.Generic.Table
|
2021-04-27 00:26:13 +03:00
|
|
|
Rel8.Generic.Table.ADT
|
2021-04-30 17:04:48 +03:00
|
|
|
Rel8.Generic.Table.Record
|
2021-04-18 02:52:15 +03:00
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Order
|
|
|
|
|
|
|
|
|
|
Rel8.Query
|
|
|
|
|
Rel8.Query.Aggregate
|
|
|
|
|
Rel8.Query.Distinct
|
|
|
|
|
Rel8.Query.Each
|
|
|
|
|
Rel8.Query.Either
|
2021-06-17 20:12:45 +03:00
|
|
|
Rel8.Query.Evaluate
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Query.Exists
|
|
|
|
|
Rel8.Query.Filter
|
2023-07-11 16:32:24 +03:00
|
|
|
Rel8.Query.Function
|
2021-07-16 18:18:43 +03:00
|
|
|
Rel8.Query.Indexed
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Query.Limit
|
|
|
|
|
Rel8.Query.List
|
2023-03-28 20:50:29 +03:00
|
|
|
Rel8.Query.Loop
|
|
|
|
|
Rel8.Query.Materialize
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Query.Maybe
|
|
|
|
|
Rel8.Query.Null
|
|
|
|
|
Rel8.Query.Opaleye
|
|
|
|
|
Rel8.Query.Order
|
2021-10-22 16:25:14 +03:00
|
|
|
Rel8.Query.Rebind
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Query.Set
|
|
|
|
|
Rel8.Query.SQL
|
|
|
|
|
Rel8.Query.These
|
|
|
|
|
Rel8.Query.Values
|
2022-10-14 04:06:07 +03:00
|
|
|
Rel8.Query.Window
|
2021-03-23 16:30:28 +03:00
|
|
|
|
|
|
|
|
Rel8.Schema.Context.Nullify
|
|
|
|
|
Rel8.Schema.Dict
|
2023-07-15 18:24:36 +03:00
|
|
|
Rel8.Schema.Escape
|
2021-07-07 18:15:06 +03:00
|
|
|
Rel8.Schema.Field
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Schema.HTable
|
|
|
|
|
Rel8.Schema.HTable.Either
|
|
|
|
|
Rel8.Schema.HTable.Identity
|
|
|
|
|
Rel8.Schema.HTable.Label
|
|
|
|
|
Rel8.Schema.HTable.List
|
2021-03-24 17:25:14 +03:00
|
|
|
Rel8.Schema.HTable.MapTable
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Schema.HTable.Maybe
|
|
|
|
|
Rel8.Schema.HTable.NonEmpty
|
|
|
|
|
Rel8.Schema.HTable.Nullify
|
2021-04-18 18:35:48 +03:00
|
|
|
Rel8.Schema.HTable.Product
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Schema.HTable.These
|
|
|
|
|
Rel8.Schema.HTable.Vectorize
|
2021-03-24 05:13:15 +03:00
|
|
|
Rel8.Schema.Kind
|
2021-03-24 21:37:55 +03:00
|
|
|
Rel8.Schema.Name
|
2021-04-08 00:35:40 +03:00
|
|
|
Rel8.Schema.Null
|
2023-07-11 15:06:36 +03:00
|
|
|
Rel8.Schema.QualifiedName
|
2021-04-15 19:00:12 +03:00
|
|
|
Rel8.Schema.Result
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Schema.Spec
|
|
|
|
|
Rel8.Schema.Table
|
|
|
|
|
|
Statements overhaul (support for statement-level `WITH`) (#250)
The motivation behind this PR is to add support for PostreSQL's `WITH` syntax at the statement level, which gives the ability to, e.g., delete some rows from a table and then re-insert those deleted rows into another table, without any round-trips between the application and the database.
To support this, this PR introduces a new type called `Statement`, which represents a single PostgreSQL statement. It has a `Monad` instance which allows sub-statements (such as `DELETE` and `INSERT` statements) to be composed together and their results bound to values that can be referenced in subsequent sub-statements. These "compound" statements are then rendered as a `WITH` statement.
`select`, `insert`, `update` and `delete` have all been altered to produce the `Statement` type described above instead of the `Hasql.Statement` type.
Some changes were necessary to the `Returning` type. `Returning` previously bundled two different concepts together: whether or not to generate a `RETURNING` clause in the SQL for a manipulation statement, and how to decode the returned rows (if any). It was necessary to break these concepts apart because with `WITH` we need the ability to generate manipulation statements with `RETURNING` clauses that are never actually decoded at all (the results just get passed to the next statement without touching the application).
Now, the `Returning` type is only concerned with whether or not to generate a `RETURNING` clause, and the question of how to decode the returned the result of the statement is handled by the `run` functions. `run` converts a `Statement` into a runnable `Hasql.Statement`, decoding the result of the statement as a list of rows. The other variations, `run_`, `runN`, `run1`, `runMaybe` and `runVector` can be used when you want to decode as something other than a list of rows.
This also gains us support for decoding the result of a query directly to a `Vector` for the first time, which brings a performance improvement over lists for those who need it.
2023-07-07 13:29:15 +03:00
|
|
|
Rel8.Statement
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Statement.Delete
|
|
|
|
|
Rel8.Statement.Insert
|
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE (#85)
This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`).
Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert".
Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour.
Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables.
Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected.
In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
2021-07-15 02:30:59 +03:00
|
|
|
Rel8.Statement.OnConflict
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Statement.Returning
|
Statements overhaul (support for statement-level `WITH`) (#250)
The motivation behind this PR is to add support for PostreSQL's `WITH` syntax at the statement level, which gives the ability to, e.g., delete some rows from a table and then re-insert those deleted rows into another table, without any round-trips between the application and the database.
To support this, this PR introduces a new type called `Statement`, which represents a single PostgreSQL statement. It has a `Monad` instance which allows sub-statements (such as `DELETE` and `INSERT` statements) to be composed together and their results bound to values that can be referenced in subsequent sub-statements. These "compound" statements are then rendered as a `WITH` statement.
`select`, `insert`, `update` and `delete` have all been altered to produce the `Statement` type described above instead of the `Hasql.Statement` type.
Some changes were necessary to the `Returning` type. `Returning` previously bundled two different concepts together: whether or not to generate a `RETURNING` clause in the SQL for a manipulation statement, and how to decode the returned rows (if any). It was necessary to break these concepts apart because with `WITH` we need the ability to generate manipulation statements with `RETURNING` clauses that are never actually decoded at all (the results just get passed to the next statement without touching the application).
Now, the `Returning` type is only concerned with whether or not to generate a `RETURNING` clause, and the question of how to decode the returned the result of the statement is handled by the `run` functions. `run` converts a `Statement` into a runnable `Hasql.Statement`, decoding the result of the statement as a list of rows. The other variations, `run_`, `runN`, `run1`, `runMaybe` and `runVector` can be used when you want to decode as something other than a list of rows.
This also gains us support for decoding the result of a query directly to a `Vector` for the first time, which brings a performance improvement over lists for those who need it.
2023-07-07 13:29:15 +03:00
|
|
|
Rel8.Statement.Rows
|
|
|
|
|
Rel8.Statement.Run
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Statement.Select
|
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE (#85)
This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`).
Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert".
Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour.
Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables.
Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected.
In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
2021-07-15 02:30:59 +03:00
|
|
|
Rel8.Statement.Set
|
|
|
|
|
Rel8.Statement.SQL
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Statement.Update
|
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE (#85)
This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`).
Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert".
Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour.
Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables.
Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected.
In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
2021-07-15 02:30:59 +03:00
|
|
|
Rel8.Statement.Using
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Statement.View
|
Add upsert support and allow arbitrary queries in INSERT, UPDATE and DELETE (#85)
This PR makes several changes to our "manipulation" functions (`insert`, `update`, `delete`).
Firstly, we now support `ON CONFLICT DO UPDATE`, aka "upsert".
Secondly, we now allow the insertion of arbitrary queries (not just static `VALUES`). `values` recovers the old behaviour.
Thirdly, our `Update` and `Delete` statements now support `FROM` and `USING` clauses respectively, allowing joining against other tables.
Fourthly, `Returning` is now an `Applicative`, which means you can say `returning = pure ()` if you don't care about the number of rows affected.
In terms of generating the SQL to implement these features, it was unfortunately significantly less work to roll our own here than to add this upstream to Opaleye proper, because it would have required more refactoring than I felt comfortable doing.
2021-07-15 02:30:59 +03:00
|
|
|
Rel8.Statement.Where
|
2021-03-23 16:30:28 +03:00
|
|
|
|
|
|
|
|
Rel8.Table
|
2021-05-01 12:21:57 +03:00
|
|
|
Rel8.Table.ADT
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.Aggregate
|
|
|
|
|
Rel8.Table.Alternative
|
|
|
|
|
Rel8.Table.Bool
|
2021-07-06 15:57:41 +03:00
|
|
|
Rel8.Table.Cols
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.Either
|
|
|
|
|
Rel8.Table.Eq
|
2021-04-30 20:13:06 +03:00
|
|
|
Rel8.Table.HKD
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.List
|
|
|
|
|
Rel8.Table.Maybe
|
|
|
|
|
Rel8.Table.Name
|
|
|
|
|
Rel8.Table.NonEmpty
|
2022-05-20 14:34:45 +03:00
|
|
|
Rel8.Table.Null
|
2021-07-05 04:42:35 +03:00
|
|
|
Rel8.Table.Nullify
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.Opaleye
|
|
|
|
|
Rel8.Table.Ord
|
|
|
|
|
Rel8.Table.Order
|
2021-07-07 18:15:06 +03:00
|
|
|
Rel8.Table.Projection
|
2021-05-01 12:21:57 +03:00
|
|
|
Rel8.Table.Rel8able
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.Serialize
|
|
|
|
|
Rel8.Table.These
|
2021-07-07 13:36:11 +03:00
|
|
|
Rel8.Table.Transpose
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Table.Undefined
|
2022-10-14 04:06:07 +03:00
|
|
|
Rel8.Table.Window
|
2021-03-23 16:30:28 +03:00
|
|
|
|
|
|
|
|
Rel8.Type
|
2021-03-23 21:16:33 +03:00
|
|
|
Rel8.Type.Array
|
2021-04-18 23:34:50 +03:00
|
|
|
Rel8.Type.Composite
|
2023-10-06 18:15:35 +03:00
|
|
|
Rel8.Type.Decimal
|
2023-09-27 13:39:04 +03:00
|
|
|
Rel8.Type.Decoder
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Type.Eq
|
2021-04-18 23:34:50 +03:00
|
|
|
Rel8.Type.Enum
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Type.Information
|
2021-03-23 18:14:48 +03:00
|
|
|
Rel8.Type.JSONEncoded
|
|
|
|
|
Rel8.Type.JSONBEncoded
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Type.Monoid
|
Expand use of `QualifiedName` to types, composites, enums (#263)
Types in PostgreSQL can also be qualified with a schema. However, it's not sufficient to just change the type of `TypeInformation`'s `typeName` to `QualifiedName`, because a type isn't *just* a name. Postgres types can also be parameterised by modifiers (e.g., `numeric(7, 2)`) and array types of arbitrary depth (e.g., `int4[][]`).
To accomodate this, a new type is introduced, `TypeName`. Like `QualifiedName`, it has an `IsString` instance, so the common case (`schema` set to `Nothing`, no modifiers, scalar type) will continue working as before.
2023-07-23 19:12:02 +03:00
|
|
|
Rel8.Type.Name
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Type.Num
|
|
|
|
|
Rel8.Type.Ord
|
2023-09-27 13:39:04 +03:00
|
|
|
Rel8.Type.Parser
|
|
|
|
|
Rel8.Type.Parser.ByteString
|
|
|
|
|
Rel8.Type.Parser.Time
|
2021-03-23 18:14:48 +03:00
|
|
|
Rel8.Type.ReadShow
|
2021-03-23 16:30:28 +03:00
|
|
|
Rel8.Type.Semigroup
|
|
|
|
|
Rel8.Type.String
|
|
|
|
|
Rel8.Type.Sum
|
|
|
|
|
Rel8.Type.Tag
|
|
|
|
|
|
2022-10-14 04:06:07 +03:00
|
|
|
Rel8.Window
|
|
|
|
|
|
|
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
test-suite tests
|
|
|
|
|
type: exitcode-stdio-1.0
|
|
|
|
|
build-depends:
|
|
|
|
|
base
|
|
|
|
|
, bytestring
|
|
|
|
|
, case-insensitive
|
|
|
|
|
, containers
|
2023-04-14 12:56:03 +03:00
|
|
|
, data-dword
|
2021-03-23 16:30:28 +03:00
|
|
|
, hasql
|
2021-07-16 11:27:57 +03:00
|
|
|
, hasql-transaction
|
2024-03-18 18:22:03 +03:00
|
|
|
, hedgehog ^>= 1.0 || ^>= 1.1 || ^>= 1.2 || ^>= 1.3 || ^>= 1.4 || ^>= 1.5
|
2021-07-16 11:27:57 +03:00
|
|
|
, mmorph
|
2023-04-14 12:56:03 +03:00
|
|
|
, network-ip
|
2021-03-23 16:30:28 +03:00
|
|
|
, rel8
|
|
|
|
|
, scientific
|
|
|
|
|
, tasty
|
|
|
|
|
, tasty-hedgehog
|
|
|
|
|
, text
|
|
|
|
|
, time
|
|
|
|
|
, tmp-postgres ^>=1.34.1.0
|
2021-07-16 11:27:57 +03:00
|
|
|
, transformers
|
2021-03-23 16:30:28 +03:00
|
|
|
, uuid
|
|
|
|
|
|
2021-07-02 15:11:47 +03:00
|
|
|
other-modules:
|
|
|
|
|
Rel8.Generic.Rel8able.Test
|
|
|
|
|
|
2021-03-23 16:30:28 +03:00
|
|
|
main-is: Main.hs
|
|
|
|
|
hs-source-dirs: tests
|
|
|
|
|
default-language: Haskell2010
|
|
|
|
|
ghc-options:
|
|
|
|
|
-Weverything -Wno-unsafe -Wno-safe -Wno-missing-safe-haskell-mode
|
|
|
|
|
-Wno-missing-import-lists -Wno-prepositive-qualified-module
|
|
|
|
|
-Wno-deprecations -Wno-monomorphism-restriction
|
|
|
|
|
-Wno-missing-local-signatures -Wno-implicit-prelude
|
Statements overhaul (support for statement-level `WITH`) (#250)
The motivation behind this PR is to add support for PostreSQL's `WITH` syntax at the statement level, which gives the ability to, e.g., delete some rows from a table and then re-insert those deleted rows into another table, without any round-trips between the application and the database.
To support this, this PR introduces a new type called `Statement`, which represents a single PostgreSQL statement. It has a `Monad` instance which allows sub-statements (such as `DELETE` and `INSERT` statements) to be composed together and their results bound to values that can be referenced in subsequent sub-statements. These "compound" statements are then rendered as a `WITH` statement.
`select`, `insert`, `update` and `delete` have all been altered to produce the `Statement` type described above instead of the `Hasql.Statement` type.
Some changes were necessary to the `Returning` type. `Returning` previously bundled two different concepts together: whether or not to generate a `RETURNING` clause in the SQL for a manipulation statement, and how to decode the returned rows (if any). It was necessary to break these concepts apart because with `WITH` we need the ability to generate manipulation statements with `RETURNING` clauses that are never actually decoded at all (the results just get passed to the next statement without touching the application).
Now, the `Returning` type is only concerned with whether or not to generate a `RETURNING` clause, and the question of how to decode the returned the result of the statement is handled by the `run` functions. `run` converts a `Statement` into a runnable `Hasql.Statement`, decoding the result of the statement as a list of rows. The other variations, `run_`, `runN`, `run1`, `runMaybe` and `runVector` can be used when you want to decode as something other than a list of rows.
This also gains us support for decoding the result of a query directly to a `Vector` for the first time, which brings a performance improvement over lists for those who need it.
2023-07-07 13:29:15 +03:00
|
|
|
-Wno-missing-kind-signatures
|
