v0.18.43

v0.18.43

• An output column with no AS alias is now named the way PostgreSQL names it:
  ?column? for an expression, a literal or a predicate; the function's own
  name for a call or an aggregate (count, sum, abs, coalesce, case);
  the ARGUMENT's name for a cast (CAST(g AS bigint) is g), and the type's
  name only when the argument has none. SELECT * over a derived table whose
  item had no name publishes ?column? too. Values are unchanged; this is the
  name a client reads out of RowDescription.
• Several output columns may now carry the same name — SELECT g + 1, g + 2 is
  two columns called ?column?, as in PostgreSQL. Read such a result
  positionally (QueryResult.Cells, or any wire client).
• A query that refers to an unnamed derived column still spells it with the
  inner block's own text (SELECT "g + 1" FROM (SELECT g + 1 FROM t) s);
  "?column?" is refused, naming the column that exists.
• An aggregate output aliased like a GROUP BY key — SELECT COUNT(*) AS g, g AS x FROM t GROUP BY g — answers correctly when read through a CTE or
  through two or more derived tables. It previously returned the key's values
  under the aggregate's name on the distributed engine.
• A derived table in a subquery's FROM that references the enclosing query is
  now refused as an unsupported shape (SQLSTATE 0A000) naming two workarounds,
  instead of being reported as a missing FROM-clause entry. The SQL is legal;
  this engine has no lowering for it yet.
• EXTRACT(field FROM x) reports the column name extract, TRIM(x) reports
  btrim, POSITION(x IN y) reports position and arr[1] reports arr,
  matching PostgreSQL.
• A SET OPERATION is the one exception to the naming rule: its output columns
  keep the leftmost arm's own spelling (g + 1), not PostgreSQL's ?column?.
  Alias the arm's items to choose the name.
• The HTTP door sends a positional values array beside rows, and the gRPC
  Row message a values list — on the unary and the streaming RPC alike —
  whenever two output columns share a name, because a JSON object and a
  protobuf map can each carry only one of them. columns is always the full
  ordered list, and both fields are absent for a result whose names are unique,
  so existing clients are unaffected.
• The HTTP door returns SELECT * columns in TABLE order (it was Go
  map-iteration order), and a zero-row result now carries the declared column
  list instead of an empty one.