{"slug": "six-postgres-19-features-your-coding-agent-does-not-know-about", "title": "Six Postgres 19 Features Your Coding Agent Does Not Know About", "summary": "Postgres 19, which reached beta on June 4, adds six features that coding agents without GitHits fail to identify, according to a test by GitHits. The test showed that an agent without GitHits incorrectly stated that core Postgres lacks SQL/PGQ graph pattern-matching syntax and IGNORE NULLS in window functions, both of which are new in Postgres 19.", "body_md": "[Back to blog](/blog/)\n\nJuly 21, 2026 · 8 min read\n\n# Six Postgres 19 Features Your Coding Agent Does Not Know About\n\nWe used GitHits to explore the Postgres 19 release and surface what changed. Six features came back. A coding agent without GitHits could not reach any of them.\n\nThis post did not start with a list of features. It started with a question: ask a coding agent what is new in a database release, and does it actually know?\n\nPostgres 19 reached beta on June 4. We connected GitHits to a coding agent and asked it to work through the release from source, then report on what was new and what it changed for anyone writing queries. The six features below are what came back. We had not picked them in advance.\n\nThen we ran the second half of the test. For each feature we wrote the prompt a developer would plausibly type, and ran it through the same agent twice: once with GitHits enabled, once without. Same model, same prompt, fresh context, one prompt at a time so no answer could lean on another.\n\nWithout GitHits, the agent did not reach any of the six. Not partially, not with hedging. In every case it explained that the thing being asked for was not available in core Postgres, and offered the workaround that was correct before this release. Below is each prompt, both answers, and what actually shipped.\n\n## Two management hops up an org chart\n\nStart with a graph traversal, the kind of query you would write against an org chart.\n\n**Prompt**\n\nI have an\n\n`employees`\n\ntable with a`reports_to`\n\nself-reference. Using only core Postgres, no extensions and no separate graph database, write a query using graph pattern-matching syntax that finds everyone exactly two management hops above ‘Alice’.\n\n**Without GitHits**\n\nNot possible in core PostgreSQL. PostgreSQL has recursive CTEs, but no core graph pattern-matching syntax. Use a recursive CTE instead.\n\n**With GitHits**\n\n```\nCREATE PROPERTY GRAPH employee_graph\n  VERTEX TABLES (\n    employees KEY (id)\n      LABEL employee\n      PROPERTIES (id, name)\n  )\n  EDGE TABLES (\n    employees AS reports_to_edge\n      SOURCE KEY (id) REFERENCES employees (id)\n      DESTINATION KEY (reports_to) REFERENCES employees (id)\n      LABEL reports_to\n  );\n\nSELECT manager_name\nFROM GRAPH_TABLE (\n  employee_graph\n  MATCH (alice IS employee WHERE alice.name = 'Alice')\n        -[IS reports_to]->()\n        -[IS reports_to]->(manager IS employee)\n  COLUMNS (manager.name AS manager_name)\n);\n```\n\nThe answer without GitHits describes Postgres as it was a year ago, and a year ago it was correct. Postgres 19 adds SQL/PGQ, the SQL:2023 property graph standard, with `CREATE PROPERTY GRAPH`\n\nand `GRAPH_TABLE`\n\n. A recursive CTE still works, but it answers a different question than the one asked. The prompt asked for graph syntax, and that syntax now exists.\n\n## The last non-null value in a gappy series\n\nAnyone working with sensor data or event streams has wanted this and hit the same wall.\n\n**Prompt**\n\nI have\n\n`sensor_readings(sensor_id, ts, reading)`\n\nwhere`reading`\n\nis frequently NULL. For each row, return the most recent non-null reading at or before that row’s timestamp, partitioned by sensor, in one query with no self-joins or lateral workarounds.\n\n**Without GitHits**\n\nNot possible in core PostgreSQL with those constraints. PostgreSQL does not support\n\n`LAST_VALUE(reading) IGNORE NULLS`\n\n. This needs a workaround such as a self-join, lateral lookup, recursive query, or custom aggregate.\n\n**With GitHits**\n\n```\nSELECT\n  sensor_id,\n  ts,\n  reading,\n  last_value(reading) IGNORE NULLS OVER (\n    PARTITION BY sensor_id\n    ORDER BY ts\n    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW\n  ) AS latest_non_null_reading\nFROM sensor_readings;\n```\n\nFor most of Postgres history, “no `IGNORE NULLS`\n\n” was simply true, and the lateral-join workaround is well documented, so the agent reaches for it. This is also a case where web search would not have helped much, since most of what is written on the subject still describes the old behavior. Postgres 19 added `IGNORE NULLS`\n\nand `RESPECT NULLS`\n\nto `lead`\n\n, `lag`\n\n, `first_value`\n\n, `last_value`\n\n, and `nth_value`\n\n. The single line the agent ruled out is the answer.\n\n## A random timestamp for test data\n\nA small one, but the kind of thing you write often.\n\n**Prompt**\n\nGive me a Postgres expression that returns a random\n\n`timestamptz`\n\nbetween two given timestamps, without hand-rolling interval math.\n\n**Without GitHits**\n\nNot possible with a built-in timestamp-range random function. PostgreSQL has\n\n`random(min, max)`\n\nfor numeric types, not`timestamptz`\n\n. A random`timestamptz`\n\nrequires interval or epoch arithmetic.\n\n**With GitHits**\n\n```\nSELECT random(\n  '2026-07-10 00:00:00+00'::timestamptz,\n  '2026-07-11 00:00:00+00'::timestamptz\n);\n```\n\nWorth noting how much the agent gets right here. It knows `random`\n\ngained numeric bounds in an earlier release and recalls the old signature correctly. It does not know that 19 added `date`\n\n, `timestamp`\n\n, and `timestamptz`\n\noverloads, so it sends you back to epoch arithmetic you no longer need.\n\n## Sequences during a near-zero-downtime upgrade\n\nA question a DBA actually loses sleep over, and one where a stale answer costs you at cutover.\n\n**Prompt**\n\nI’m setting up logical replication between two Postgres clusters for a near-zero-downtime major upgrade. After cutover, do I have to manually resync sequence values on the subscriber, or is there a setup that keeps sequences in sync automatically? Show the setup.\n\n**Without GitHits**\n\nIn core PostgreSQL logical replication, sequence changes are not kept in sync automatically. Before allowing writes on the upgraded subscriber, resync sequences manually, for example with\n\n`setval('public.users_id_seq', (SELECT max(id) FROM public.users), true)`\n\n.\n\n**With GitHits**\n\n```\n-- publisher\nCREATE PUBLICATION upgrade_pub\nFOR ALL TABLES, ALL SEQUENCES;\n\n-- subscriber\nCREATE SUBSCRIPTION upgrade_sub\nCONNECTION 'host=publisher dbname=app user=repl password=...'\nPUBLICATION upgrade_pub\nWITH (copy_data = true);\n\n-- resync before cutover\nALTER SUBSCRIPTION upgrade_sub REFRESH SEQUENCES;\n```\n\nFor years, “logical replication does not carry sequences” was dependable enough to state as a rule, and the agent states it as one. Postgres 19 changed it. Publications can now include sequences with `ALL SEQUENCES`\n\n, and `ALTER SUBSCRIPTION ... REFRESH SEQUENCES`\n\nbrings their values across. One detail worth keeping straight: this syncs at subscribe and refresh rather than continuously, which is the shape a cutover needs. Left alone, the agent would have you scripting `setval`\n\nfor a problem the release already handles.\n\n## Turning on checksums without an outage\n\nThe last two are quick, because the shape is familiar by now.\n\n**Prompt**\n\nMy running Postgres cluster has data checksums disabled. How do I enable them without taking the cluster offline or running\n\n`pg_checksums`\n\nin offline mode?\n\n**Without GitHits**\n\nYou cannot enable data checksums online in core PostgreSQL.\n\n`pg_checksums --enable`\n\nrequires the cluster to be shut down cleanly; there is no online core equivalent.\n\n**With GitHits**\n\n```\nSELECT pg_enable_data_checksums();\n\n-- optionally throttle the background rewrite\nSELECT pg_enable_data_checksums(cost_delay => 10, cost_limit => 1000);\n```\n\nFor thirteen years the correct answer was to shut the cluster down. Postgres 19 added `pg_enable_data_checksums()`\n\nand `pg_disable_data_checksums()`\n\n, which flip checksums on a live cluster while a background worker rewrites every page. The agent gave the answer that was true until this release.\n\n## URL-safe base64\n\n**Prompt**\n\nEncode a\n\n`bytea`\n\nto a URL-safe base64 string in Postgres, the variant using`-`\n\nand`_`\n\ninstead of`+`\n\nand`/`\n\n, with a built-in and not a manual`replace()`\n\n.\n\n**Without GitHits**\n\nNot possible with a built-in base64url encoder. Core\n\n`encode()`\n\nsupports`base64`\n\n,`hex`\n\n, and`escape`\n\n, but not URL-safe base64 without post-processing.\n\n**With GitHits**\n\n```\nSELECT encode('\\xdeadbeef'::bytea, 'base64url');\n```\n\nSmaller surface, same result. `encode`\n\nand `decode`\n\ngained `base64url`\n\nand `base32hex`\n\nin 19. The agent listed the old formats as though that list were still complete.\n\n## What the six have in common\n\nTwo things are worth separating here.\n\nThe first is that the agent did not know about these features, which on its own is unremarkable. The second is more useful: it also could not tell that it did not know. Across all six prompts it answered quickly and in the same tone it uses when it is right, and it never flagged that the version might have moved. Each “not possible” meant “not possible in the Postgres I know about,” but nothing in the output marks that distinction. The answers that are wrong read the same as the answers that are right.\n\nNone of these features are obscure. All six are in the [Postgres 19 release notes](https://www.postgresql.org/docs/19/release-19.html), and we traced each one back to the Postgres source before publishing. They are ordinary additions, and they are new.\n\nThat is also why GitHits closes the gap without touching the model. Same model, same weights in both runs. Everything the agent needed was public and retrievable, sitting in the source tree the whole time. What it lacked was any reason to go looking, because it did not perceive a gap. GitHits reads the source for the version in question and puts those facts in front of the model before it answers, which accounts for the entire difference between the two answers.\n\nPostgres 19 is a convenient example because the release is recent enough that the misses are easy to check. The same thing happens more quietly with any library, framework, or API that has shipped a version the model does not know about, where the wrong answer arrives just as confidently and you have no release notes open to catch it. The six prompts here are reproducible. Enable GitHits and run them yourself.", "url": "https://wpnews.pro/news/six-postgres-19-features-your-coding-agent-does-not-know-about", "canonical_source": "https://githits.com/blog/postgres-19-coding-agents-githits/", "published_at": "2026-07-21 00:00:00+00:00", "updated_at": "2026-07-22 01:39:51.890936+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "large-language-models"], "entities": ["Postgres 19", "GitHits", "PostgreSQL"], "alternates": {"html": "https://wpnews.pro/news/six-postgres-19-features-your-coding-agent-does-not-know-about", "markdown": "https://wpnews.pro/news/six-postgres-19-features-your-coding-agent-does-not-know-about.md", "text": "https://wpnews.pro/news/six-postgres-19-features-your-coding-agent-does-not-know-about.txt", "jsonld": "https://wpnews.pro/news/six-postgres-19-features-your-coding-agent-does-not-know-about.jsonld"}}