<p></p>
<p dir="auto">We have an issue with the way we are handling schemas that we need to solve. This has been made worse <a href="https://www.crunchydata.com/blog/be-ready-public-schema-changes-in-postgres-15" rel="nofollow">with the changes in PostgreSQL 15 around schema permissions</a>.</p>
<p dir="auto">Historically osm2pgsql didn't support schemas at all, everything was simply done without mentioning any schema, which normally meant tables, indexes, etc. ended up in the <code class="notranslate">public</code> schema which is always there and used to be writable by every database user. Then users wanted to be able to put tables, etc. into specific schemas, so we added functionality for that. If you set a schema (on the command line or in the flex config file), that schema is used, otherwise the former behaviour is used.</p>
<p dir="auto">Note that there is a difference between "not using a schema at all" and "using the <code class="notranslate">public</code> schema". In the second case the schema is hardcoded to be <code class="notranslate">public</code>, it just happens to be the one that would also be used by default in many cases. In the first case no schema is specified, which means PosgtreSQL will use the <code class="notranslate">search_path</code> and uses the first schema that exists in that search path to create objects. By default the <code class="notranslate">search_path</code> is <code class="notranslate">"$user", public</code> which means if there is a schema with the name of the user running osm2pgsql, that schema is used, otherwise <code class="notranslate">public</code> is used.</p>
<p dir="auto">It used to be that nobody has a schema with the name of their user, so no schema basically meant <code class="notranslate">public</code>. But with the change in Pg 15 this assumption is wrong. The <code class="notranslate">public</code> schema isn't writable any more in databases that you don't own, which lead to more people using schemas, specifically the schema with the same name as their user, which is what a lot of docs recommend you do. This breaks the implicit assumption that "no schema == <code class="notranslate">public</code>" which we have in our minds and which is also in our code in some places.</p>
<p dir="auto">Now there are probably three common setups for osm2pgsql databases:</p>
<ol dir="auto">
<li>Use one user as owner of the database and use the <strong>same</strong> user for osm2pgsql. In that case you don't need any special schemas, the owner of the database can create objects in the <code class="notranslate">public</code> schema.</li>
<li>Use one user as owner of the database and use a <strong>different</strong> user for osm2pgsql. Add a schema with the same name as the user used by osm2pgsql, don't mention any schemas on the osm2pgsql command line/config. That schema should be used by osm2pgsql if the <code class="notranslate">search_path</code> was not changed from the default. (This case is currently broken by some assumption in the case that "no schema == <code class="notranslate">public</code>".)</li>
<li>Create specific schema(s) for osm2pgsql and explicitly use them on the command line/config. No problem there.</li>
</ol>
<p dir="auto">Now there is the question how we want things to be. There are basically two options:</p>
<ol dir="auto">
<li>Remove any assumptions in the code that  "no schema == <code class="notranslate">public</code>". Things will mostly "just work", but the user will have to understand how the <code class="notranslate">search_path</code> affects schema choice and that they possibly need that schema named after the user. Any fiddling with the <code class="notranslate">search_path</code> will affect the behaviour of osm2pgsql, possibly breaking things in more or less subtle ways, especially if the <code class="notranslate">search_path</code> is changed after import but before updates are run or so.</li>
<li>Always force use of a schema everywhere in the osm2pgsql code. The default would change from "no schema" to the <code class="notranslate">public</code> schema. If you can't write to the public schema osm2pgsql will error out early on. We can clearly tell the user what to do in that case (create schema, set the schema in osm2pgsql or make <code class="notranslate">public</code> writable). Changes to the <code class="notranslate">search_path</code> will not affect osm2pgsql any more. The code becomes simpler, because we don't need to differentiate any more between "no schema" and "some schema". Users don't have to understand the details of the <code class="notranslate">search_path</code> any more.</li>
</ol>
<p dir="auto">This issue came to light now with <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1817283618" data-permission-text="Title is private" data-url="https://github.com/openstreetmap/osm2pgsql/issues/2010" data-hovercard-type="issue" data-hovercard-url="/openstreetmap/osm2pgsql/issues/2010/hovercard" href="https://github.com/openstreetmap/osm2pgsql/issues/2010">#2010</a> which is caused by a "no schema == <code class="notranslate">public</code>" assumption in the new code that deals with the <code class="notranslate">osm2pgsql_properties</code> table. To figure out whether that table exists the code checks the <code class="notranslate">pg_tables</code> table in the database and it uses <code class="notranslate">public</code> as schema. What we would have to do is take the <code class="notranslate">search_path</code> into account for that check which would be difficult. Instead we probably would just try to read from the table and if that fails assume that the table is not there.</p>
<p dir="auto">All in all I think option (2) would be the better solution, because it is conceptually simpler and doesn't rely on the <code class="notranslate">search_path</code>. But it is a change from current behaviour and would mean some users will have to add command line options / configs settings which they didn't have to do before.</p>
<p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/pnorman/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/pnorman">@pnorman</a>, <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/lonvia/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/lonvia">@lonvia</a> opinions?</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/osm2pgsql/issues/2011">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AA6353UTS6DBSDWHDNYX67TXRYYR7ANCNFSM6AAAAAA2VHXCXU">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AA6353UHE57JB6VMPVXNG23XRYYR7A5CNFSM6AAAAAA2VHXCXWWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGYW34ZY.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/osm2pgsql/issues/2011</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/osm2pgsql/issues/2011",
"url": "https://github.com/openstreetmap/osm2pgsql/issues/2011",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>