Support for execution of any single or multi query statements with discarded completions/rows

[rolang]

Hi, I was looking for a way to execute any statements without being able to know in advance whether it's going to be a query or command as well as whether it'll contain single or multiple queries which is currently not possible.

Use case with some background:
We are using skunk in our code base for database access which has been working out great. For running migrations / versioning the database though we are still seeking support from flyway. Considering that we only use a fraction of Flyway features, only with Postgres and we already have a library for database access which could take care of that, it adds a lot of dependencies on top like JDBC with drivers and keeps us tied to the JVM. Flyway cli also ships with a jre.

I am attempting to replace Flyway with dumbo. For that I'd like to read any SQL statements from a file, send it to Postgres and let it take care of the rest. Returned Completions/Rows are not really relevant. I'm currently missing the ability to let skunk just send any kind of statement, query or command, single or multiple to Postgres without the need to parse the contents or split into single statements.

I currently ended up with adding an extended Session version as in this PR that ships with a "simple"

def execute_(statement: Statement[Void]): F[Unit]

and was wondering whether this or something similar could be considered as part of skunk 🤔

Related issue about multi-query statements support: #695
This one is maybe also somewhat related #959

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 87.50000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 85.56%. Comparing base (3f99149) to head (60f0e5d).
Report is 155 commits behind head on main.

Files with missing lines	Patch %	Lines
modules/core/shared/src/main/scala/Session.scala	50.00%	1 Missing ⚠️
...ore/shared/src/main/scala/net/protocol/Query.scala	92.30%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1023      +/-   ##
==========================================
+ Coverage   85.54%   85.56%   +0.01%     
==========================================
  Files         135      135              
  Lines        2041     2057      +16     
  Branches      239      228      -11     
==========================================
+ Hits         1746     1760      +14     
- Misses        295      297       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mpilquist]

This seems like a good idea. Any ideas for a better name than execute_?

[rolang]

This seems like a good idea. Any ideas for a better name than execute_?

How about executeDiscard (or executeDiscarded)?
I picked the idea with the _ from cats where you have methods like traverse or sequence etc. going in pair with traverse_ / sequence_ as versions with discarded output, I thought it may fit as it builds on top of cats.
E.g. similar functionality in ZIO is named like foreach / foreachDiscard, foreachPar / foreachParDiscard etc.

[rolang]

I guess I could also add a version which accepts arguments if this extension is ok like:
def executeDiscard[A](statement: Statement[Void])(args: A): F[Unit] and also try to improve the code coverage.
I was not sure yet what to do with NoticeResponse messages, this one is not covered in the test.

[rolang]

Update:

• Renamed execute_ to executeDiscard. Another name I just thought of is executeVoid, how about that 🤔 ?
• Discarding NoticeResponse as well instead of failing (not sure it needs to fail on that)
• updated sample queries in tests (something similar I've seen in the "wild" being done in migration scripts)

---

I guess I could also add a version which accepts arguments

I think I underestimated that one. It would make this pull request somewhat bigger 🤔 I guess it would need to run through prepare as well and require a new type like PreparedStatement along with PreparedQuery / PreparedCommand? Maybe it can be done as part of another update.