<div dir="ltr"><div>PostGIS hackers/developers,</div><div><br></div><div>Does this addition make sense?</div><div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 14, 2025 at 11:07 AM Jeevan Chalke <<a href="mailto:jeevan.chalke@enterprisedb.com">jeevan.chalke@enterprisedb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>While working with one of our customers, we observed that <font face="monospace">pg_upgrade</font> is failing with PostGIS.<br><br>What is happening is (SQL attached below), the user table <font face="monospace">"prosch"."MyTab"</font> has a column of type <font face="monospace">"public"."geography"</font>, which, in turn, references a row in <font face="monospace">public.spatial_ref_sys</font>. While there is a recorded dependency between <font face="monospace">"procsch"."</font><font face="monospace">MyTab"</font> and <font face="monospace">"public"."geography"</font>, no such dependency exists between <font face="monospace">"public".</font><font face="monospace">"geography"</font> and <font face="monospace">public.spatial_ref_sys</font>.<br><br>As a result, while the type <font face="monospace">"public"."geography"</font> is created before the user table, <font face="monospace">spatial_ref_sys</font> is not. Due to sorting (in <font face="monospace">pg_dump</font>), the user table is dumped before <font face="monospace">spatial_ref_sys</font>, leading to an error during restoration.<br><br>Since PostgreSQL does not maintain dependencies at the row level (and thus not for tables containing such rows), the extension itself should explicitly define this dependency. This would ensure that <font face="monospace">public.spatial_ref_sys</font> is dumped before the type <font face="monospace">"public"."geography"</font>, preventing issues during dump and restore.<br><br>If we manually add the dependency in the source database, <font face="monospace">pg_upgrade</font> will work well. The query to achieve this is:<br><br><font face="monospace">INSERT INTO pg_depend VALUES (<br> 'pg_catalog.pg_type'::regclass::oid, 'public.geography'::regtype::oid, 0,<br> 'pg_catalog.pg_class'::regclass::oid, 'public.spatial_ref_sys'::regclass::oid, 0,<br> 'n');</font><br><br>Can this be considered a valid request and added to the extension SQL file itself?<br><br>---<br><br>Here is the SQL sequence that yields an error (shared by one of our engineers)<br><br></div><div><font face="monospace">CREATE SCHEMA procsch;<br>CREATE TABLE "procsch"."MyTab" (<br> "id" bigint,<br> "loc" "public"."geography"(Point,4283)<br>);<br><br>INSERT INTO procsch.MyTab VALUES (1, ST_GeomFromText('POINT(152.138672 -30.689888)', 4283));<br><br>$ strings /PATH/bin/pg_dump | grep POSTGIS_spatial<br>POSTGIS_spatial_ref_sys<br>$<br><br>/PATH/bin/initdb -D /srv/13/data/pg_data<br>/PATH11/bin/pg_ctl -D /srv/11/data/pg_data -l logfile stop<br>/PATH/bin/pg_upgrade --check --link --old-datadir=/srv/11/data/pg_data --new-datadir=/srv/13/data/pg_data --old-bindir=/PATH11/bin --new-bindir=/PATH/bin --old-port=5432 --new-port=5434<br># for real, no --check:<br>/PATH/bin/pg_upgrade --link --old-datadir=/srv/11/data/pg_data --new-datadir=/srv/13/data/pg_data --old-bindir=/PATH11/bin --new-bindir=/PATH/bin --old-port=5432 --new-port=5434</font><br><br><br>And it did blow up with : <br><br><br><font face="monospace">[..]<br>pg_restore: creating TABLE "procsch.MyTab"<br>pg_restore: while PROCESSING TOC:<br>pg_restore: from TOC entry 371; 1259 17425 TABLE MyTab u1<br>pg_restore: error: could not execute query: ERROR: relation "public.spatial_ref_sys" does not exist<br>LINE 21: "loc" "public"."geography"(Point,4283)<br> ^<br>QUERY: SELECT proj4text, auth_name, auth_srid, srtext FROM public.spatial_ref_sys WHERE srid = 4283 LIMIT 1<br>[..]<br>CREATE TABLE "procsch"."MyTab" (<br> "id" bigint,<br> "loc" "public"."geography"(Point,4283)<br>);<br>[..]</font></div><div><br></div><div><br></div><div>Thanks</div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr"><img width="200" height="37" src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUmLsFZCrsP0IzlqcrOBS4LG-QdOAM_CPz15Rip0P4elztKb7pS0FF_Tbb_lCOORByN9lcXUTXqe-8"><br></div><div dir="ltr"><br></div><div dir="ltr"><b>Jeevan Chalke</b><br><span style="color:rgb(29,28,29);font-family:Slack-Lato,Slack-Fractions,appleLogo,sans-serif"><i>Principal Engineer, Engineering Manager</i></span><i><br>Product Development</i><br><span style="font-size:11pt;font-family:Arial;color:rgb(255,62,0);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br><a href="https://www.enterprisedb.com" target="_blank">enterprisedb.com</a></span></div></div></div></div></div></div></div></div></div>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr"><img width="200" height="37" src="https://ci3.googleusercontent.com/mail-sig/AIorK4wUmLsFZCrsP0IzlqcrOBS4LG-QdOAM_CPz15Rip0P4elztKb7pS0FF_Tbb_lCOORByN9lcXUTXqe-8"><br></div><div dir="ltr"><br></div><div dir="ltr"><b>Jeevan Chalke</b><br><span style="color:rgb(29,28,29);font-family:Slack-Lato,Slack-Fractions,appleLogo,sans-serif"><i>Principal Engineer, Engineering Manager</i></span><i><br>Product Development</i><br><span style="font-size:11pt;font-family:Arial;color:rgb(255,62,0);background-color:rgb(255,255,255);font-weight:700;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br><a href="https://www.enterprisedb.com" target="_blank">enterprisedb.com</a></span></div></div></div></div></div></div></div></div></div>