<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Articles on pgmi</title><link>https://vvka-141.github.io/pgmi/articles/</link><description>Recent content in Articles on pgmi</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 15 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://vvka-141.github.io/pgmi/articles/index.xml" rel="self" type="application/rss+xml"/><item><title>AI agents write PostgreSQL like Python</title><link>https://vvka-141.github.io/pgmi/articles/ai-agents-write-postgresql-like-python/</link><pubDate>Wed, 15 Jul 2026 00:00:00 +0000</pubDate><guid>https://vvka-141.github.io/pgmi/articles/ai-agents-write-postgresql-like-python/</guid><description>&lt;h1 id="ai-agents-write-postgresql-like-python"&gt;AI agents write PostgreSQL like Python&lt;a class="anchor" href="#ai-agents-write-postgresql-like-python"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;&lt;em&gt;By Alexey Evlampiev&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Give a coding agent a PostgreSQL-first backend to build and it will write you working SQL. It will also, with remarkable consistency, write you &lt;em&gt;Python&lt;/em&gt; — Python&amp;rsquo;s exception-driven control flow, Python&amp;rsquo;s trust in casts, Python&amp;rsquo;s habit of validating wherever the code happens to be — transliterated into PL/pgSQL, where those idioms carry costs the agent never sees.&lt;/p&gt;
&lt;p&gt;This article is a field report. It draws on two internal reviews of a production line-of-business backend built database-first — a few hundred SQL files across roughly two dozen domains, with a kernel/handler split and a thin HTTP gateway — where AI coding agents wrote most of the SQL. The reviews rated every finding and verified each against the code before reporting it. The failure modes below are the ones that recurred; the discipline in the second half is what the same codebase used, in its healthy majority, to avoid them.&lt;/p&gt;</description></item><item><title>Test PostgreSQL migrations before COMMIT</title><link>https://vvka-141.github.io/pgmi/articles/test-postgresql-migrations-before-commit/</link><pubDate>Sat, 11 Jul 2026 00:00:00 +0000</pubDate><guid>https://vvka-141.github.io/pgmi/articles/test-postgresql-migrations-before-commit/</guid><description>&lt;h1 id="test-postgresql-migrations-before-commit"&gt;Test PostgreSQL migrations before COMMIT&lt;a class="anchor" href="#test-postgresql-migrations-before-commit"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;&lt;em&gt;By Alexey Evlampiev&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Most migration pipelines test before deployment or after commit. PostgreSQL
allows a third checkpoint: &lt;strong&gt;after applying the change, but before committing
it&lt;/strong&gt;. Lint and rehearsal catch what they can in advance; integration suites
catch what they can afterwards. The checkpoint in between is the only one
where the real target database — with whatever drift it has accumulated — is
in its migrated state while rollback is still one statement away.&lt;/p&gt;</description></item></channel></rss>