Merged PRs

doltgresql

• 2763: Bug fix for null literals in records
• 2760: properly flush results
  Instead of flushing RowDescription and every RowData right away, have the entire Result buffer in memory first.
• 2759: more concurrency when spooling results
  This PR splits the convert to wire format and send to client steps into two threads.
  Copies optimization from gms: dolthub/go-mysql-server#3310
• 2757: add all benchmarks, add perf scripts, remove debug logs
  This PR changes the quick-sysbench.sh config to using logging mode info.
  Debug logs can slow down benchmarks with all that additional IO, so they should be disabled while benchmarking.
  The list of quick benchmarks has also been updated to include every read and write benchmark; it should take around 15 minutes to complete now.
  Additionally, this PR adds some utility scripts to make it easier to profile and benchmark a single test.
• 2743: support WHERE predicate in indexes

Closed Issues

Merged PRs

doltgresql

• 2747: Add tests for DROP INDEX
  Depends on: dolthub/go-mysql-server#3555
• 2740: Update docs URLs to new paths
  Migrate all docs.dolthub.com, docs.doltgres.com references to the new dolthub.com/docs, doltgres.com/docs URLs in the READMEs.
• 2730: support array_to_json and row_to_json functions
  Depends on: dolthub/go-mysql-server#3551
• 2729: bug fix: load non-built-in types when looking for an array type's element type
  Various bug fixes for regressions reported in PR #2642, primarily related to resolving arrays of non-built-in types. The major change is adding ctx to the ArrayBaseType() method, but not all call sites could be updated, so unfortunately results in a new ArrayBaseTypeCtx(ctx) method until we can find a way to always provide a sql context and completely remove the old method form.
• 2720: Fix scripts/build.sh to work on RedHat-based distros
  On CentOS and other RH-based distros the output of "go version" contains the "(Red Hat 1.26.2-2.el10)" string, which confuses the parser.
• 2694: fix: correct deserialization order of sequence/routine/membership in …
  …auth
  The serialize() function wrote fields in this order:
  tablePrivileges → sequencePrivileges → routinePrivileges → roleMembership
  But deserializeV1() read them in a different order:
  tablePrivileges → roleMembership → routinePrivileges → sequencePrivileges
  This mismatch went unnoticed because all three sections (sequencePrivileges, routinePrivileges, roleMembership) have the same zero-value byte representation (count=0) when no privileges exist. Once GRANT ALL PRIVILEGES ON ALL ROUTINES or GRANT ALL PRIVILEGES ON ALL FUNCTIONS is executed, routinePrivileges becomes non-empty, the reader offset shifts, and doltgres panics with an index out of range error on the next startup when attempting to read the persisted auth file.
  Fix deserializeV1() to match the order used by serialize().
  Fixes #2693
• 2692: Bug fix: don't round JSON numeric values when outside of float64 range
  Fixes: #2686
• 2688: Bug fix: include view columns in pg_catalog.pg_attribute
  Adds columns in views to pg_catalog.pg_attribute to match PostgreSQL behavior.
  This requires parsing and analyzing the view, which may require caching if performance for queries on pg_attribute becomes slow when many complex views are present.
  Fixes: #2682
• 2687: Bug fix for out of bounds slice access
  Fixes: #2684
• 2668: Bump lodash from 4.17.21 to 4.18.1 in /testing/postgres-client-tests/node
  Bumps lodash from 4.17.21 to 4.18.1.
  Release notes

  Sourced from lodash's releases.

  4.18.1

  Bugs

  Fixes a ReferenceError issue in lodash lodash-es lodash-amd and lodash.template when using the template and fromPairs functions from the modular builds. See lodash/lodash#6167

  These defects were related to how lodash distributions are built from the main branch using https://github.com/lodash-archive/lodash-cli. When internal dependencies change inside lodash functions, equivalent updates need to be made to a mapping in the lodash-cli. (hey, it was ahead of its time once upon a time!). We know this, but we missed it in the last release. It's the kind of thing that passes in CI, but fails bc the build is not the same thing you tested.

  There is no diff on main for this, but you can see the diffs for each of the npm packages on their respective branches:

  • lodash: lodash/lodash@4.18.0-npm...4.18.1-npm
  • lodash-es: lodash/lodash@4.18.0-es...4.18.1-es
  • lodash-amd: lodash/lodash@4.18.0-amd...4.18.1-amd
  • lodash.templatelodash/lodash@4.18.0-npm-packages...4.18.1-npm-packages

  4.18.0

  v4.18.0

  Full Changelog: lodash/lodash@4.17.23...4.18.0

  Security

  _.unset / _.omit: Fixed prototype pollution via constructor/prototype path traversal (GHSA-f23m-r3pf-42rh, fe8d32e). Previously, array-wrapped path segments and primitive roots could bypass the existing guards, allowing deletion of properties from built-in prototypes. Now constructor and prototype are blocked unconditionally as non-terminal path keys, matching baseSet. Calls that previously returned true and deleted the property now return false and leave the target untouched.

  _.template: Fixed code injection via imports keys (GHSA-r5fr-rjxr-66jc, CVE-2026-4800, 879aaa9). Fixes an incomplete patch for CVE-2021-23337. The variable option was validated against reForbiddenIdentifierChars but importsKeys was left unguarded, allowing code injection via the same Function() constructor sink. imports keys containing forbidden identifier characters now throw "Invalid imports option passed into _.template".

  Docs

  • Add security notice for _.template in threat model and API docs (#6099)
  • Document lower > upper behavior in _.random (#6115)
  • Fix quotes in _.compact jsdoc (#6090)

  lodash.* modular packages

  Diff

  We have also regenerated and published a select number of the lodash.* modular packages.

  These modular packages had fallen out of sync significantly from the minor/patch updates to lodash. Specifically, we have brought the following packages up to parity w/ the latest lodash release because they have had CVEs on them in the past:

  • lodash.orderby
  • lodash.tonumber
  • lodash.trim
  • lodash.trimend
  • lodash.sortedindexby
  • lodash.zipobjectdeep
  • lodash.unset
  • lodash.omit
  • lodash.template

  Commits

  • cb0b9b9 release(patch): bump main to 4.18.1 (#6177)
  • 75535f5 chore: prune stale advisory refs (#6170)
  • 62e91bc docs: remove n_ Node.js < 6 REPL note from README (#6165)
  • 59be2de release(minor): bump to 4.18.0 (#6161)

Merged PRs

doltgresql

• 2601: Fixes 2462, 2574, 2579, 2604
  This fixes:
  • #2462
  • #2574
  • #2579
  • #2604
    The array concatenation functions are tested independently in existing tests with the exception of array_prepend, which is new (hence the lack of new tests for those functions).
• 2597: allow SELECT; and column name for cast result fix
• 2596: Fixed user/pass issue for initialization scripts, added docs
  Fixes #2300
• 2588: Add support for UTF8 chars in identifiers
  Enables use of UTF8 chars in identifiers, matching PostgreSQL behavior.
  Related to #2580
• 2587: add a stack trace to recovered panic
• 2583: DEALLOCATE ALL
  Fixes #2575
• 2570: support nested block statements and call statement in plpgsql
• 2562: Support using same parameter multiple times
  Right now we always don't allow a query to use the same parameter in multiple locations.
  Technically that should always be allowed and then we'll fail later down the line if you're trying to bind a parameter and compare it to something with an incompatible type.
  But the error messages we have if I just completely remove the check are a little ugly, so I added some code to our function that handles the types of parameters by breaking if you try to use a parameter as multiple incompatible types within the same query.
  So for instance the query: select * from table where column_int = $1 and column_float4 = $1 should be fine because integer/int4 is compatible with float4.
  But the query: select * from table where column_text = $1 and column_int = $1 will error because text and integer/int4 are not compatible.
• 2558: fix type resolution in select of create view stmt

Closed Issues

• 2604: dolt_merge fails with "at or near "<index_name>": syntax error" on 3-way merge when table has both UNIQUE INDEX and a column with DEFAULT clause
• 2579: Array operator || not implemented
• 2574: SELECT 'now'::timetz --> spurious error
• 2462: PostgreSQL Compatibility: SET TIME ZONE '<offset>' fails with invalid value parameter error
• 2578: Enums: reported column attribute is incorrect
• 2573: Empty SELECT --> spurious error
• 2146: pg_tables system table: tableowner column is incorrect
• 2300: Docker entrypoint exec_sql hardcodes postgres/password credentials, ignoring DOLTGRES_USER/DOLTGRES_PASSWORD
• 2580: UTF8 table names not supported
• 2575: DEALLOCATE ALL --> spurious error
• 2250: Feature request: Support indexing expressions on columns
• 2546: SELECT 'foo' --> invalid OID 705
• 2547: concat('', NULL, '') incorrectly returning null string
• 2548: Timezone parser does not accept PostgreSQL-accepted formats (time zone offset)

Merged PRs

doltgresql

• 2560: Fixed issues 2547 and 2557
  This fixes:
  • #2547
  • #2557
    This introduces a new function type which mirrors the C-language variadic function implementation. These functions differ from standard PostgreSQL variadic functions, as normally variadic functions require that all variadic parameters have the same type. This limitation is not true for C-language functions. This was required to implement a valid concat function, as we were previously relying on GMS' built-in version, which is not correct for Postgres. I also corrected some tests that enforced the incorrect behavior.
    This also fixes a bug in JSON parsing. It was already known that Go's JSON library converts escaped characters into their original forms, however we were attempting to preemptively handle the incorrect conversion. This has been changed, as we can cleanup the output since the unescaped forms are invalid JSON anyway, which fixes the behavior and makes our output more accurate.
• 2554: Fixed issues 2546 and 2548
  This PR fixes:
  • #2546
  • #2548
• 2529: Fixed ANY using bindings
  This fixes:
  • #2386
    In GMS/MySQL, we often can't determine the type of a bound parameter during the initial parse as the return type is subject to the input (binding a float32 vs int32 may result in an actual return type difference). This is not true for Postgres as type resolution is very well defined. This creates a mismatch where we defer the type resolution, but the client expects to be told what type the bindings should be.
    We should have a more general solution that covers bindings at the GMS layer for how MySQL and Postgres handle type resolution differently, but the scope of that project seemed too large for now, so this only implements a local fix specifically for the issue linked above.
• 2501: allow running multiple statements in function

Closed Issues

• 2546: SELECT 'foo' --> invalid OID 705
• 2547: concat('', NULL, '') incorrectly returning null string
• 2548: Timezone parser does not accept PostgreSQL-accepted formats (time zone offset)
• 2545: Suggestion: include Doltgres brand in version string
• 2557: unescaped newlines in JSON output
• 2423: information_schema.columns cannot be queried with dolt_show_system_tables set
• 2386: Error when running parameterized any clause.

Merged PRs

doltgresql

• 2503: Fixed DST handling by moving to timeofday
time.Time serialization and deserialization can cause information to be irreversibly lost due to daylight savings time changes. The location isn't directly serialized due to it being tied to the runtime system information (different operating systems may have different time zone information), and is therefore reconstructed on deserialization.
  This is fine for timestamptz, as we internally process everything as UTC and use the client's timezone when returning values to the client. For timetz, however, the timezone information is embedded in the value itself and is independent of the client, and this was causing information loss during serialization. This PR changes serialization to use the timetz.TimeTZ type, which is already used at most steps (by casting time.Time to timetz.TimeTZ and vice-versa), and therefore the change propagates to all functions that take a timetz value.
  In line with this, the time type was updated to use timeofday.TimeOfDay, which is also already used internally in most functions. Although serialization is fine, this was changed to be more inline with timetz (as timetz.TimeTZ directly uses timeofday.TimeOfDay) and also due to time.Time carrying implicit information that can cause direct value comparisons to be incorrect. For example, '01:00:00'::time should sort before '02:00:00'::time, however adding 24 hours to the first value will still result in the correct hour mark for display, but internally the time.Time value would be on the next day, and would cause the comparison to actually show '02:00:00'::time appearing first (assuming they started on the same day to begin with).
  All of these issues are fixed by using the correct types that are already in Doltgres, and already used by the internal functions. I'm not sure why we decided to use time.Time instead of those anyway (as interval uses the internal type rather than casting to time.Duration), but this fixes it. This does mean that the serialization is incompatible with existing databases, however since serialization was incorrect in the first place, it's a necessary change.
• 2496: /.github/workflows: bump actions checkout
• 2494: add is distinct and not distinct from exprs
• 2490: resolve user defined type in drop routine
• 2487: Added proper support for receiving binary formatted values
  This is the receive counterpart to the following PR:
  • #2394
    All new tests were validated against a live Postgres 15 server to ensure that we're processing client input properly. In addition, I've added a little more testing on the send side as well, as there were a couple of small gaps in coverage.
• 2478: remove ValidateTagUniqueness
  companion pr: dolthub/dolt#10707
• 2476: Misc Fixes for Prisma
  3 things in this PR:
  1. Makes version numbers consistent. I used 15.17 which is the latest version of postgresql 15.
  2. Make the col_description, obj_description, and shobj_description return the correct value for "no comments", rather than "empty comments". They are still no-op functions but now return NULL instead of empty strings. More detailed information on these functions can be found here
  3. generate_subscripts is a set returning function that returns the indices of the array you give it. So for instance the array [10, 40, 23] will return {1, 2, 3}. Most postgresql array types are 1-indexed, except for the types oidvector and int2vector. I added a fix so that generate_subscripts respects those two's unique indexing. More on generate_subscripts here. oidvector and int2vector don't seem to have standard docs pages but this site provides basic details.
• 2472: add fors plpgsql statement
• 2464: Support creating/dropping DB with hypens in name
  Adds functionality and testing for creating databases like test-db.
  Currently: create database "test-db" will create a database called "test-db" (with the escaped quotes).
  drop database "test-db" will try to look for a database called "test-db" to drop (with the escaped quotes).
• 2458: Moved the binary wire format for receiving to the receive func
• 2454: resolve type with database provided
• 2447: support fori plpgsql statement

Closed Issues

• 2333: UPDATE SET date_column = '2026-02-14' fails without explicit ::date cast via simple protocol

Merged PRs

doltgresql

• 2443: Added proper dolt_branch_control functionality
  Fixes:
  • #2435
    This fixes two primary issues with dolt_branch_control. The first is that we'd error when encountering a destination GMS type, as we make the assumption that all GMS types have been handled once we reach a certain point in the analyzer. This is false for Dolt system tables that may be modified, so now cast those types to their closest Doltgres type for analysis.
    The second fix deals with how superusers are handled between Doltgres and GMS. Doltgres uses its own permission model since it's fundamentally different than GMS' model, but dolt_branch_control internally checks for a superuser (or pseudo-superuser) to allow some commands without explicit privileges given. This adds a layer of indirection so that checks for superusers specifically will work as expected.
• 2439: check for 'check_function_bodies' configuration parameter…
  … when creating functions
  Depends on: dolthub/go-mysql-server#3465
• 2415: Support text array parameters
  Prisma blocking bug. Right now if you try to bind a query with a text array we scan it incorrectly and error out.
• 2413: Added additional testing for TIMESTAMP
  This adds testing for TIMESTAMP and TIMESTAMPTZ, which were missing. This also adds a step in CI that changes the locale to the west coast since we already had such assumptions in other tests (that were eventually changed), and there's no other way to test timezones otherwise.
• 2408: support int2vector and oidvector types
• 2402: #2373 fix VALUES subquery unwrap from dropping clauses

  Summary

  • Replace overly permissive len(inSelect.From) == 1 guard in nodeAliasedTableExpr with isTrivialSelectStar, which only unwraps bare SELECT * FROM (VALUES ...)
    subqueries with no additional clauses (projections, LIMIT, ORDER BY, DISTINCT, WHERE, GROUP BY, HAVING)
  • Add *plan.Offset guard to TypeSanitizer to prevent OFFSET literals inside subqueries from being converted to Doltgres types, which caused GMS validateOffsetAndLimit
    to reject them with "invalid type: bigint"
  • Un-skip mixed-type VALUES-in-subquery tests and add mixed-type variants plus OFFSET-specific assertions
    Closes: #2373
• 2384: support privileges for routines and sequences
  Depends on: dolthub/go-mysql-server#3450

Closed Issues

• 2435: INSERT INTO dolt_branch_control fails with "non-Doltgres type found in destination
• 2388: Cannot call unnest on pg_index column indoption.
• 2373: Bug: VALUES inside subquery ignores projections, LIMIT, and ORDER BY

Merged PRs

doltgresql

• 2395: information schema sequences
  Adds sequences to information_schema, following the specification outlined by Postgresql here.
• 2394: Implemented the binary wire format
  Fixes:
  • #2317
  • #2347
  • #2348
  • #2360
  • #2362
    In a nutshell, we did not respect a client's wishes when they requested that the results for some columns are returned in their binary format (obtained from their send function). Instead, we had hardcoded that some types, in certain circumstances, would only return their binary format, while others would strictly return their text format. This PR implements the binary wire format for every type that is currently supported. This also fixes numerous bugs that were hidden due to our incorrect behavior.
    In addition to the above fixes, this PR introduces a new test harness for analyzing our compatibility with the wire messages returned directly to Postgres clients. Thousands of lines of new tests have been added that ensure we're returning the exact correct results for a given set of messages (not just queries but the actual client messages), and the test harness allows for quick iteration when comparing what a Postgres server sends versus a Doltgres server, so we can ensure that we're returning the same bytes, not just the same overall structure.
• 2187: #1648: fix VALUES clause type inference

  Summary

  VALUES clause type inference now uses PostgreSQL's common type resolution algorithm instead of using only the first row's type.
  existing issue: SELECT * FROM (VALUES(1),(2.01),(3)) v(n) failed with integer: unhandled type: decimal.Decimal

  Changes

  • Add ResolveValuesTypes analyzer rule that:
  • Collects types from all VALUES rows (not just the first)
  • Uses FindCommonType() to resolve per PostgreSQL's [UNION/CASE type resolution](https://www.postgresql.org/docs/15/typeconv-union-case.html; per FindCommonType doc comment)
  • Applies implicit casts to convert values to the common type
  • Updates GetField expressions in parent nodes (handles aggregates like SUM)
  • Add UnknownCoercion expression for unknown to target type coercion
  • add go and bats tests

  Questions for Reviewers

  1. Analyzer rule approach: Is adding this as an analyzer rule (after TypeSanitizer) the right approach? I considered alternatives but this seemed cleanest for handling the two-pass transformation needed for GetField updates. Open to feedback if there's a better pattern.
  2. PostgreSQL version: The code references PostgreSQL 15 docs. Should this stay as-is since doltgresql targets PG 15, or should it use /docs/current/?
     Fixes: #1648

Closed Issues

• 2362: COUNT(*) returns wrong value via binary protocol (extended query)
• 2360: Extended protocol sends JSONB as raw JSON text instead of binary JSONB format (missing 0x01 version prefix)
• 2348: Extended protocol sends incorrect binary format for ENUM columns, causing client-side decode panic
• 2347: Extended protocol sends empty binary payload for NUMERIC/DECIMAL columns, causing client panic
• 2317: Extended protocol SELECT fails with 'permission denied for table pg_type'
• 1648: the first value in VALUES should not determine the column type

Merged PRs

doltgresql

• 2353: allow cte in CREATE VIEW
  Also fixes:
  • string_agg with separator cast with text type
  • fix parse procedure and sequence name in GRANT privileges ON statement
• 2350: add plpgsql-dynexecute statement for CREATE FUNCTION
  Also fixes:
  • type resolution in DECLARE
  • add support for TG_OP special variable usage for triggers
• 2349: Checking for table relation respects temporary tables
  Fixes #2326
  When checking for whether a root has a relation, we should respect temporary tables in addition to our existing checks for regular tables.
• 2346: Added test framework for testing wire data
  This is a precursor for:
  • #2317
    Currently, we have no in-engine way of ensuring that the proper data is received on the wire for any given sequence of messages that were sent. This means that we must rely on client tests to ensure that the correct data is sent, with the expectation that they'll fail if we change something. This isn't conducive to our standard debugging workflow, so this adds the ability to perform wire tests and verification from within the Go testing environment, which is resistant to change (client tests could fail due to a library update that is outside of our control) and easily debuggable.
    For most of these tests, I'll be using WireShark to ensure that our output is exactly the same as a standard Postgres server.

Closed Issues

• 2326: Cannot create keyless temporary tables with serial columns

Merged PRs

doltgresql

• 2327: bugfix: support records containing non-DoltgresType values
• 2324: resolve type with empty search path

Closed Issues

Merged PRs

doltgresql

• 2323: Fixed issues 2316 and 2318
  This fixes:
  • #2316
  • #2318
    For 2316, clients may only send a single format code that should apply to multiple values, but we assumed that their lengths always matched. This is fixed by extending the format code slice length to the same as the value slice if there is a single format code provided.
    For 2318, it appears that Rust wants these values in binary format, so now we're returning them in binary format. I'm not sure why Rust doesn't accept text format like everything else does, but perhaps it's the default in Postgres so some ORMs only work with the default.
    It's worth mentioning that tests for these exist only within the client tests, as I could not replicate the errors within our standard testing framework. As mentioned with the binary format, it seems that Rust isn't as permissive as other ORMs, so we have to test with Rust specifically.

Closed Issues

• 2318: Extended protocol sends TIMESTAMPTZ and DATE as text instead of binary format
• 2316: Extended protocol INSERT/UPDATE/DELETE crashes with 'index out of range [1] with length 1'