MCPDBWizard for Postgres 2.0.35

A composite or a statement row now always crosses under its Postgres names. Regenerate a server
to get it.

docker pull ghcr.io/srmadscience/mcpdbwizard-postgres:2.0.35
docker pull docker.io/srmadscience/mcpdbwizard-postgres:2.0.35

• Changed: a name Java cannot hold no longer becomes a Java name over MCP. A composite's
  attributes and a statement's columns already crossed under their own names when those were legal
  Java identifiers, which most are. One that is not — a quoted alias like "Sequence Owner", an
  attribute like "country#fk", two names differing only in punctuation — crossed as the field name
  the generator had to invent (Sequence_Owner, country_fk, a numbered a_b2). It now crosses
  as itself. A statement selecting the same label twice still numbers the second, since one object
  cannot carry two of a key.

  This breaks a client that hard-codes one of the invented names. An agent reads the schemas
  afresh each session and needs nothing; an old key is refused with an error rather than ignored.
  A server keeps its old keys until it is regenerated.

• Fixed: a tool could be checked against another tool's input schema. The MCP Java SDK caches
  each tool's compiled input schema under a hash of the schema, and two different schemas can hash
  alike. When they did, whichever tool was called first lent its schema to the other: valid calls to
  the second were refused (for example "required property 'a' not found"), and the same mix-up could
  let an invalid call through. Which tools are affected depends on the schemas and on call order.
  Every generated server now keys that cache by the schema's full text. Regenerate to pick this up.

• Fixed: a VECTOR field inside a record was missing from the composite's schema. The field still
  bound, but a caller reading the schema could not see it. It is now published as an array of
  numbers, as a vector parameter is.

• Fixed: two tools with the same name stopped the whole server at start-up. A tool name is the
  object's name with every character outside letters and digits made an underscore, so two
  different objects can arrive at the same one. The later one now gets the first free suffix (_2,
  _3, …), and the generation log says which object took which name. Every name that already worked
  is unchanged.

• New: generation names every selected object it could not find. A routine, table or sequence
  that was dropped or renamed since the config was saved, or that the login can no longer see, used
  to be left out of a batch build without a word. Each is now a warning naming the object and what to
  check.

• Fixed: a generator run that lost its database connection could exit 0 with nothing generated.
  It now exits 3, so a build script stops instead of carrying on with a missing or partial tree.

• Fixed: the post-generation script never ran on Linux or macOS. A config's POST_SCRIPT_CONTENT
  is written to POST_SCRIPT_NAME and run after generation, but the file was written without
  execute permission, so every run on Linux or macOS failed with Permission denied and carried on
  without saying so beyond a line in the log. It now runs. Windows was unaffected.

• Fixed: with WEB_SERVICES=YES, a selected SQL statement could stop the rest of the web-service
  code being generated. Generation reported an error and carried on, leaving the service class
  short of the methods that came after the statement.

MCPDBWizard for Postgres 2.0.34

Two fixes, chiefly to the console's Design page. Nothing needs regenerating unless you want the
sequence description fix.

docker pull ghcr.io/srmadscience/mcpdbwizard-postgres:2.0.34
docker pull docker.io/srmadscience/mcpdbwizard-postgres:2.0.34

Fixed

• A config's procedures could show as unselected, and saving them removed them. A config made
  with the desktop generator, or converted from a .pb2 file, records a routine that is not in a
  package as having the package "null". The Procedures tab did not recognise that spelling, so
  after uploading such a config it showed none of its procedures ticked, although the config still
  selected them and the running server still had their tools. Pressing Save on that tab then
  removed every one of them from the config, and ticking them again first brought them back
  without their tool descriptions. The configs in the public hotel demo had this spelling until
  9 November 2026, so if you uploaded them and saved the Procedures tab, check the demo's
  procedures and descriptions, or upload the configs again. The demo's configs are corrected, so
  they also work on earlier images.
• The tool description of a sequence whose name needs quoting (one with a space in it, for
  example) showed stray backslashes, \"my seq\". Regenerate a server to pick this up; it changes
  only that description.

MCPDBWizard for Postgres 2.0.33

Generated output changes. Upgrade, and regenerate your servers. Pressing Start on the console
regenerates a server from its config, so restarting each server after pulling the new image is
enough.

docker pull ghcr.io/srmadscience/mcpdbwizard-postgres:2.0.33
docker pull docker.io/srmadscience/mcpdbwizard-postgres:2.0.33

Changes an MCP client will notice

• Some tool names change. A tool name may be 64 characters at most, and a longer one used to
  be cut to its first 55 characters plus a hash. Postgres tool names carry the schema and
  identifiers can be 63 bytes long, so the cut often fell inside the table name, and every tool
  on a long-named table ended in the same ..._<table fragment>_<hash>. The descriptions were the
  only way to tell them apart. A long name is now its first 23 characters, the same 8-digit hash,
  and its last 31 characters, so the operation stays at the end:
  dbhell_longusernamexxxx_c1bc51b2_ablexxxxxxxxxxxxxxxxx_get_by_pk. Only names that 2.0.32
  shortened change: a name of 64 characters or fewer is exactly as before. If a client, a prompt
  or an allow-list names a shortened tool, update it after regenerating.
• Timestamps keep their microseconds. Over MCP a timestamp used to cross with milliseconds
  only, in both directions, so .123456 came back as .123. Worse, a lookup keyed on a value that
  get_by_pk had just returned could miss the row. Timestamps now cross at full precision. They
  are written with every digit down to the last non-zero one, never fewer than three, and a
  timestamp parameter now accepts the JDBC form (2026-11-03 10:55:00.123456) as well as ISO. A
  value in whole milliseconds reads and writes exactly as before.
• A row set holds at most 10,000 rows by default, as on Oracle. A routine returning a
  refcursor used to return every row. A tool returning a bigger cursor now returns its first
  10,000.
• No rowInsert on a view that cannot take one. An aggregate view or a materialized view used
  to get an insert tool that could only fail. A tool is now generated only when Postgres says the
  relation accepts INSERT (pg_relation_is_updatable). A simple view keeps its insert tool.
• Multi-row lookups come back in primary-key order, as on Oracle. Index and foreign-key child
  lookups had no ORDER BY before, so their rows came back in whatever order the server chose.
• Errors from table and statement tools name the SQLSTATE, ending (SQLSTATE 23502) as routine
  errors already did.
• A statement parameter hinted with a Postgres type now gets that type. A hint such as
  ? /* pKey uuid */ or /* pId bigint */ used to be ignored, so the parameter was whatever
  the server inferred, often text. It now declares the type, and the server checks the statement
  against it when the server is generated. A hint that names no type, or one the statement cannot
  take, stops that statement being generated, with a warning, rather than failing on its first
  call. Hints using the Oracle words (STRING, NUMBER, DATE) behave as before.

New

• Lookups through expression indexes. A table indexed on upper(name), date_trunc(...) or a
  field of a composite column now gets a lookup tool per such index. It used to get none for those
  indexes, and a table whose only indexes were expression indexes got no lookups at all. The
  tool's arguments are named for the index's columns (upper, building_no) and typed by the
  expression, and the query is written so that the index can serve it. A unique index returns one
  row, any other index an array. This adds tools to any schema that has an expression index.

Fixed

• Array subscripts survive a round trip. A Postgres array can start at 0, at a negative
  subscript, or anywhere else ([5:7]={...}). The generated collection classes and array fields
  in records used to drop the lower bound, so keys 0..2 came back as 1..3 and writing the value
  back moved them. Both now keep the lower bound in each direction. The JSON shape over MCP is
  unchanged.
• An array of composites can be passed in. Its tool's schema asked for an array of strings,
  which the server then refused, so the tool could not be called at all. It now takes an array of
  objects with the composite's attributes. A timestamp attribute on the way out is its wall-clock
  value, not a UTC instant.
• A key read from a timestamp(0) column finds its row again. A column with a declared
  precision rounds what it stores, so a row inserted with 12:34:56.789 (stored as 12:34:57)
  could not be found, updated or deleted by the key it was inserted with. Keys are now rounded to
  the column's own precision.
• A null compared with a number works. A null parameter of unknown type was bound as text,
  which Postgres refuses to compare with a numeric (42883). It is now bound untyped.
• Statements that stopped a config compiling:
  • a statement with a quoted identifier or alias ("Sequence Owner") was skipped;
  • DDL, ANALYZE and SAVEPOINT statements were skipped too, and now run as written;
  • a statement Postgres could not describe was skipped but still referenced, so the whole server
    failed to compile. It is now left out with a warning;
  • a parameter named 1 produced Java that did not compile;
  • a config with SQL statements but no routines generated a server that did not compile.
• Two foreign keys of the same name pointing at one table, which Postgres allows because
  constraint names are unique per table, produced two methods and two tools of one name, and the
  server did not compile. The second is now named for its child table as well.

Upgrading. Pull 2.0.33 and restart each server from the console, which regenerates it. No
config change and no database change. Supported Postgres versions are unchanged: 16, 17 and 18.