Merged PRs

dolt

• 8174: check for pg_catalog table when resolving a table
  Fixes:
  dolthub/doltgresql#442
  dolthub/doltgresql#513
• 8172: Reveal dolt archive command
  Move the dolt admin archive command to dolt archive
• 8164: archive guard rails
  Add features to ensure that archive files are not used when running a remotesrv or when pushing backups.
  Also provide the --revert flag which can return a database back to the classic format.
• 8137: Dolt index searchable, lookup caching
  Two main changes
  • cache schema hashes on root values, so that we don't have to a table lookup to get a schema hash
  • Implement sql.IndexSearchable in a way that we cache strict key lookups for a given table schema. The lifecycle for these objects is the span between ALTER TABLE statements

go-mysql-server

• 2610: use datetime precision in information_schema.columns.datetime_precision
  When determining if a schema change occurred, one of the tables Prisma looks at is the information_schema.columns.
  Here, we incorrectly mark all datetime and timestamp columns as with a precision of 6.
  If a table has type DATETIME(3), Prisma would think there was a schema change, and perform a migration when one isn't needed.
  This PR addresses this issue by having the information_schema.columns table accurately reflect the datetime preicision of the columns,
  fixes: #8173
• 2604: Index searchable edits
  We previously added support for integrators choosing their own indexes with an sql.IndexSearchable interface. This was for a customer use case. This PR expands the interface to let Dolt cache information about strict key lookups.
  The motivation is that (1) strict key lookups will always be the best-case scenario result of index costing, (2) caching this information in-between ALTER statements is usually a long enough lifecycle for the overhead to be worth it.
  I added a streamlined range builder as part of this optimization that only accepts literal values in the order expected by the target lookup. The user of this range builder takes responsibility for feeding the values in the correct order. As a result, we sidestep expensive string formatting, map creating, and map lookups during range building.
  Follow-on fixes to functional dependencies permuted plans a bit more. Inner joins are chosen more frequently in some of our test plans now that we're reflecting strict key max-1-row cardinalities.

vitess

• 360: Bug fix: Preserve sign for integers in prepared statements
  Bound integer values for prepared statements are parsed from the wire and packaged into int64 values that are then passed to the SQL engine to execute with the prepared statement. For int8, int16, int24, and int32 types those bytes from the wire weren't getting cast to the correct type first, before they were cast to int64, which meant if the signed bit was set, the value was interpreted incorrectly.
  Customer issue: #8085
• 359: fix detection of multi-statements in ComPrepare
  Currently, preparing multi-statements is not supported; so we can't prepare a query like select ?; select ?;.
  However, the check for this condition just looked for any characters after the first ;, which meant that queries like select ?; \n would incorrectly throw an error.
  This was made apparent using the Prisma ORM, which runs the query:

  SELECT TABLE_NAME AS view_name, VIEW_DEFINITION AS view_sql
  FROM INFORMATION_SCHEMA.VIEWS
  WHERE TABLE_SCHEMA = ?;

  The above query ends in a newline character.
  The fix is to use SplitStatementToPieces(), which trims these white space characters, and check if there's exactly one piece; this was taken from the vitessio repo: https://github.com/vitessio/vitess/blob/main/go/mysql/conn.go#L1204
  fixes #8157

Closed Issues

• 4127: Support for date and time literals
• 8173: prisma migrate dev, generating changes to columns of the date type in loop
• 7200: Weird behavior for datetime literal syntax.
• 8157: Error when using Prisma ORM: "Error: unknown error: can not prepare multiple statements"

Performance