v0.18.44

v0.18.44

• An IPv6 value prints the way PostgreSQL's inet prints it: a v4-mapped
  address is ::ffff:10.0.0.1 and not 10.0.0.1, and a v4-compatible one is
  ::1.2.3.4. LIKE matches that text.
• IPv6 values render about twice as fast (Vector.GetValue over an IPv6
  column: 280.5 → 141.6 µs per 2048 rows, allocations 9043 → 4096).
• PostgreSQL's boolean input grammar (t/f, yes/no, y/n, on/off, 1/0, word
  prefixes, case-insensitive, trimmed) applies to a COMPUTED boolean, not only
  to a boolean column: WHERE (NOT flag) = 'yes' answers, and a string that
  names no boolean raises 22P02 instead of answering no rows. Comparing a
  boolean against '' raises 22P02 too, instead of answering false.
• element_at reads the container it is given at any depth: a nested
  element_at, a COALESCE, a CASE or a GREATEST over MAP or ARRAY columns
  routes and compares by the container's declared element type. A MAP with a
  DECIMAL key is looked up at the key's own scale.
• An abbreviated network literal beside a column follows PostgreSQL's inet
  grammar, which is the one the server itself uses there: '10/8',
  '192.168/16', '10.1/8' and '10/008' are values, and a maskless
  abbreviation ('239', '192.168') is 22P02 exactly as it is on the
  server. A mask may not name a byte the literal did not write ('10/15' is a
  value, '10/16' is an error). Every network literal is classified once,
  when the query is planned, so the same query no longer answers or errors
  depending on the data or the execution path — including a full four-octet
  address spelled with a leading zero or a trailing dot ('010.1.2.3'), and
  an IPv6 prefix mask, which is now checked digit by digit against
  PostgreSQL's own 0-128 rule ('::1/064' is 22P02; '10.0.0.1/031' is a
  value).
• An IPv4 or MAC column now compares as the address it holds, not as its
  raw internal encoding, in IN, NOT IN, BETWEEN, and inside a CASE —
  those sites previously matched a quoted address literal against zero, on
  every execution path.
• COALESCE refuses a quoted literal its own folded type cannot read, the way
  GREATEST, LEAST and NULLIF already did — COALESCE(<int col>, 'text')
  and COALESCE(<network col>, 'zzz') are 22P02, before any row.
• Arithmetic over an aggregate keeps the aggregate's exact type through a
  derived table, a CTE, or a set operation (UNION, INTERSECT, EXCEPT):
  SUM(v * 3000000) + 1 over (SELECT c_i64 AS v FROM ...) answers
  36280278840510000001 under numeric, where it was a float8
  3.6280278840509997e+19.
• A literal compared against a BYTES column is read by PostgreSQL's byteain,
  so WHERE b = '\x6869' finds the row holding those two bytes. A malformed
  bytea literal is refused rather than compared as its own spelling, and
  '\x68 69' — whitespace inside the hex digits — is accepted, as PostgreSQL
  accepts it.
• length over BYTES counts bytes, for a stored column as well as a computed
  value, and char_length agrees with it. substring over BYTES returns
  BYTES indexed by bytes.
• text || bytea is text; bytea || bytea is bytea.
• Arithmetic over a computed aggregate through a set operation (UNION, INTERSECT, EXCEPT) whose arms declare the same type now declares and answers that exact type on every path; a set operation whose arms declare different types is a recorded open boundary and still answers float8.
• The statistics-answered MIN/MAX rewrite engages again on tables whose column names carry upper-case letters; since v0.18.30 an unquoted MIN(EventDate) had been scanning the whole column instead of reading two numbers per row group (#881).
• The ClickBench correctness and optimization-invariance gates compare duplicate-named output columns positionally (three queries were being checked over one cell), and the dialect spells Q28/Q29 with OCTET_LENGTH, the byte count the reference workload's length() means; TestHitsCorrectness is 43/43 against the DuckDB baseline again.