<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Explainers on BareSQL.com</title>
    <link>https://baresql.com/tags/explainers/</link>
    <description>Recent content in Explainers on BareSQL.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 26 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://baresql.com/tags/explainers/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How BareSQL Audit Finds Every Column a PostgreSQL Login Can Read</title>
      <link>https://baresql.com/how-baresql-audit-finds-every-column-a-postgresql-login-can-read/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/how-baresql-audit-finds-every-column-a-postgresql-login-can-read/</guid>
      <description>&lt;p&gt;PostgreSQL keeps the answer to “who can read this column?” in many places. Grants sit in access lists on tables and on single columns. Role memberships nest, and since PostgreSQL 16 each one says separately whether its rights are inherited and whether SET ROLE is allowed. Views read their tables with their owner’s rights unless they say otherwise, row security policies filter what a table hands out, and default privileges hand out tables that don’t exist yet.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How BareSQL Portable Finds SQL That Answers Differently on Four Engines</title>
      <link>https://baresql.com/how-baresql-portable-finds-sql-that-answers-differently-on-four-engines/</link>
      <pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://baresql.com/how-baresql-portable-finds-sql-that-answers-differently-on-four-engines/</guid>
      <description>&lt;p&gt;Most SQL that fails on another engine fails loudly, with a syntax error on the first run. The expensive kind runs everywhere and answers differently. On the sample shop’s products, &lt;code&gt;SUM(stock) / COUNT(*)&lt;/code&gt; is 3 on SQLite and PostgreSQL and 3.3333 on MySQL. &lt;code&gt;ORDER BY last_order&lt;/code&gt; puts the customers who never ordered first on three engines and last on PostgreSQL. A search with LIKE finds Ann on SQLite and misses her on PostgreSQL, and &lt;code&gt;&#39;1&#39; = 1&lt;/code&gt; is false on SQLite and true on the other three. None of these raise an error.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
