[gpkg] Ensure that mapping tables are inserted into gpkg_contents

Fixes auto-created relationship mapping tables cannot be read
from gpkg

autotest/ogr/ogr_gpkg.py

@@ -7203,6 +7203,16 @@ def get_query_row_count(query):
         == 1
     )
 
+    # validate mapping table was created
+    assert get_query_row_count("SELECT * FROM 'origin_table_dest_table'") == 0
+    # validate mapping table is present in gpkg_contents
+    assert (
+        get_query_row_count(
+            "SELECT * FROM gpkg_contents WHERE table_name='origin_table_dest_table' AND data_type='attributes'"
+        )
+        == 1
+    )
+
     lyr = ds.CreateLayer("origin_table2", geom_type=ogr.wkbNone)
     fld_defn = ogr.FieldDefn("o_pkey", ogr.OFTInteger)
     assert lyr.CreateField(fld_defn) == ogr.OGRERR_NONE

doc/source/drivers/vector/gpkg.rst

@@ -177,6 +177,12 @@ only be updated to change their base or related table fields, or the relationshi
 table type. It is not permissible to change the base or related table itself, or the mapping
 table details. If this is desired then a new relationship should be created instead.
 
+Note that when a many-to-many relationship is created in a GeoPackage, GDAL will always
+insert the mapping table into the gpkg_contents table. Formally this is not required
+by the Related Tables Extension (instead, the table should only be listed in gpkgext_relations),
+however failing to list the mapping table in gpkg_contents prevents it from being usable
+in some other applications (e.g. ESRI software).
+
 Dataset open options
 --------------------
 

ogr/ogrsf_frmts/gpkg/ogrgeopackagedatasource.cpp

@@ -9942,6 +9942,35 @@ bool GDALGeoPackageDataset::AddRelationship(
             return false;
         }
 
+        /*
+         * Strictly speaking we should NOT be inserting the mapping table into gpkg_contents.
+         * The related tables extension explicitly states that the mapping table should only be
+         * in the gpkgext_relations table and not in gpkg_contents. (See also discussion at
+         * https://github.com/opengeospatial/geopackage/issues/679).
+         *
+         * However, if we don't insert the mapping table into gpkg_contents then it is no longer
+         * visible to some clients (eg ESRI software only allows opening tables that are present
+         * in gpkg_contents). So we'll do this anyway, for maximum compatiblity and flexibility.
+         *
+         * More related discussion is at https://github.com/OSGeo/gdal/pull/9258
+         */
+        pszSQL = sqlite3_mprintf(
+            "INSERT INTO gpkg_contents "
+            "(table_name,data_type,identifier,description,last_change,srs_id) "
+            "VALUES "
+            "('%q','attributes','%q','Mapping table for relationship between "
+            "%q and %q',%s,0)",
+            osMappingTableName.c_str(), /*table_name*/
+            osMappingTableName.c_str(), /*identifier*/
+            osLeftTableName.c_str(),    /*description left table name*/
+            osRightTableName.c_str(),   /*description right table name*/
+            GDALGeoPackageDataset::GetCurrentDateEscapedSQL().c_str());
+
+        // Note -- we explicitly ignore failures here, because hey, we aren't really
+        // supposed to be adding this table to gpkg_contents anyway!
+        (void)SQLCommand(hDB, pszSQL);
+        sqlite3_free(pszSQL);
+
         pszSQL = sqlite3_mprintf(
             "CREATE INDEX \"idx_%w_base_id\" ON \"%w\" (base_id);",
             osMappingTableName.c_str(), osMappingTableName.c_str());