libpg_query 18.1.0

C library for accessing the PostgreSQL parser outside of the server environment

Release notes

* Security fix: Heap out-of-bounds write and read in pg_query_normalize ([GHSA-6ggm-xmc9-8ffg](https://github.com/pganalyze/libpg_query/security/advisories/GHSA-6ggm-xmc9-8ffg))
  - When normalizing certain utility statements (e.g. `DO ... LANGUAGE`, statements with
    string options, or `CREATE/ALTER SUBSCRIPTION ... CONNECTION`), pg_query_normalize
    searched the query text for the location of string constants, which could yield
    wrong locations for crafted input. This could cause out-of-bounds writes and reads
    on the heap, leaking process memory in the normalized output or crashing the process.
  - Constant locations are now recorded by the parser instead, and the normalizer checks
    at runtime that constant locations never overlap
  - This adds new location fields to the parse tree output (`DefElem.arg_location`,
    `NotifyStmt.payload_location`, `CreateSubscriptionStmt.conninfo_location` and
    `AlterSubscriptionStmt.conninfo_location`). Like other location fields, these are
    ignored for fingerprinting.
  - Applications that normalize untrusted query text should upgrade
  - Reported by Paul Gerste (Cure53)
* Deparser: Add strict checking for unexpected pointer values
  - This ensures that a bad input parse tree doesn't cause the deparser to crash, and
    instead returns an error
  - Use cases that do not work with user input can define `PG_QUERY_DEPARSE_NO_STRICT_CHECKS`
    to turn off the most detailed checks, for slightly better performance
  - Reported by Paul Gerste (Cure53)
* Add stack overflow crash protection, error out instead [#348](https://github.com/pganalyze/libpg_query/pull/348)
  - Overly deep queries now return the standard Postgres "stack depth limit exceeded"
    error instead of crashing the process
  - The allowed stack depth defaults to 100 kB, auto-sized up to 2 MB, and is
    recalculated on each call, since callers may use threads with varying stack sizes
  - Stack depth is also checked when recursing directly into specific node types (e.g.
    long `UNION` chains), and in `exprLocation` during raw parsing
* Switch Protobuf implementation from protobuf-c to upb
  - upb is developed as part of the main Protobuf project, and is substantially faster,
    in part due to its built-in arena allocation
  - upb also allows limiting parse depth for complex Protobuf input, avoiding crashes
* Update to Postgres 18.6 release
* Add `pg_query_scan_tokens` to get scan results without involving Protobuf
  - This allows pure C callers to walk a simple list of `PgQueryScanToken` structs
* Ignore comments when parsing queries, only treat them as significant for scanning [#378](https://github.com/pganalyze/libpg_query/pull/378)
  - This fixes parse errors when comments are placed between related tokens
    (e.g. `NOT /* comment */ IN`), or between string literals that get concatenated
* Parser: Avoid quadratic memory use for rules that involve dotted names [#374](https://github.com/pganalyze/libpg_query/pull/374)
* Return errors for PL/pgSQL statements without bodies [#363](https://github.com/pganalyze/libpg_query/pull/363)
  - This avoids an assertion failure or crash when `CREATE FUNCTION` or `DO` omits
    its function body
* Fingerprinting: Add fingerprint options to `pg_query_fingerprint_opts` [#361](https://github.com/pganalyze/libpg_query/pull/361)
  - This is a breaking change for callers of `pg_query_fingerprint_opts`,
    which now takes a fingerprint options bitmask as a third argument
  - By default, relation references are fingerprinted following Postgres 18+
    query ID behavior: in SELECT/DML statements the alias name replaces the
    relation name when present, and schema names are ignored
  - `PG_QUERY_FINGERPRINT_RANGEVAR_IGNORE_ALIASES` always fingerprints
    relation names and ignores aliases
  - `PG_QUERY_FINGERPRINT_RANGEVAR_INCLUDE_SCHEMA` also fingerprints schema
    names in SELECT/DML statements
  - Combining both flags (`…

Share this resource