Merged PRs

dolt

• 7297: dolt push: Only assert on a clean working set when doing a push if we are running against a server which requests it.
• 7284: dolt table import --all-text correctly infers pk if none given
  dolt table import will use the first column in the import file as the primary key if none is explicitly defined. This change updates --all-text to also correctly do this inference.
• 7283: add comments to help devs when a failure occurs
• 7278: default to text option for dolt table import
  Adds the --all-text option to dolt table import which will default all columns to TEXT type.
  Resolves: #6471
• 7264: Bh/minver improvements

go-mysql-server

• 2251: fix order by optimization
  This hopefully fixes 24 sqllogictests.
  We introduced an optimization where we would drop Sort nodes for queries that included ORDER BYs if there were IndexLookups that were a matching prefix over the sortfields. The idea was that since indexes are already in order there was no need to sort.
  However, there is a case when that isn't necessarily true. If the index is created from a filter over multiple columns, specifically when that filter contains an OR expression, it is possible to iterate over columns in a non-sorted order. During analysis, the filters are converted into several non-overlapping ranges; it is possible for a range expression in the range to overlap with another range's range expression, but for the two ranges to not overlap. It's clearer to look at the test.
  We didn't catch this bug earlier, as it only affects queries in dolt. We iterate over rows in the in-memory tables in such a way that the rows will still appear in order.
• 2249: fix decimal out of bounds in case statement
  We are failing 42 sqllogictest with the same error: Out of bounds value for decimal type.
  This is caused by Case performing a convert to a decimal type that had a bad exclusiveUpperBound.
  MySQL has specific rules about the precision , scale, and conversion of decimals, and it is difficult to match their behavior exactly.
  Fortunately, the result is correct before the conversion, so the fix here is to just use the result, and not convert.
  This is somewhat of a bandaid fix; decimal type is an area that needs more improvement in general.
  Fixes #7079
• 2246: round IndexAccess for numerical strings over int columns
  fixes #7261
• 2244: Feature: SYSDATE() function
  Adds support for the SYSDATE() function.
  Related to: #7270
• 2239: Support for doltgres prepared statements
  See dolthub/vitess#299 for new handler interface
  This includes three main changes:
  1. Implements new ExtendedHandler methods for doltgres prepared statement support
  2. Refactors the handler and engine to pull out functionality common to MySQL and Postgres prepared statement execution paths
  3. Adds type information to BindVars where they can be implicitly recognized, as required for the Describe message in Doltgres. This tells the client the postgres types required for parameters in query strings before binding. Doltgres inspects the plan node to find bindvars and their types to return to the client.
     I'm most interested in feedback on 3) before I go deeper on it. It's implemented only for insert values and comparison expressions (used in filters). A complete solution also requires support for UPDATE and probably some other expression types. If this approach is too hacky or is likely to break or interfere with other things, I want to know before continuing. If the latter, it would be pretty easy to introduce a bind context specific to this use case and not assign types unless it's set.
     See dolthub/doltgresql#87 for how doltgres uses this new bindvar type information.

vitess

• 299: Define an ExtendedHandler interface to handle postgres specific interactions
  These are pretty narrowly tailored for postgres prepared statements and long term should probably be placed in either doltgresql or another package. Defining them here is just expedient for experimenting with the new interfaces while they change.
• 298: parse empty begin end block in trigger
  14 SQL correctness tests are failing because we throw syntax errors on queries like this:

  CREATE TRIGGER t1r1 AFTER UPDATE ON t1 FOR EACH ROW BEGIN END;

Closed Issues

• 7276: Implement DATEDIFF
• 7079: Error in evaluating expression: "Out of range value for column of Decimal type"
• 6471: feature request: dolt table import add option to default to text/varchar type
• 7261: Unexpected Result when Querying with CONCAT
• 7270: Please implement SYSDATE for Mediawiki install

Latency