Open fpuga opened 2 years ago
Thanks for reporting the issue!
It does not seem like the constraints are the source of the issue (they are ignored by geodiff). The actual issue will have something to do with the content of geometry_columns
table. Geodiff runs the following query to get more information about geometry type:
SELECT f_geometry_column, type, srid, coord_dimension FROM geometry_columns
WHERE f_table_schema = '<your_schema>' AND f_table_name = '<your_table>';
Could you please check what is the result of this query for your "old" table and what does it say for a "new" table?
I check that in my tests and see no real difference.
f_table_name │ f_geometry_column │ type │ srid │ coord_dimension
═════════════════════════════════╪═══════════════════╪═════════════════╪═══════╪═════════════════
old_table │ the_geom │ MULTIPOLYGON │ 25829 │ 2
new_table │ geom │ POINT │ 4326 │ 2
Note that i'm using a different srid in the new_table
but just because i make a quick test.
I have more old tables in the schema, some of then of type POINT and LINESTRING. I can make more tests, trying to narrow the problem if you think it is useful.
I've created a reproducible example. Just note that my testing environment is PostgreSQL v9.6 and PostGIS v2.5.
Only one schema, with two tables. old_table
has been created in the past with AddGeometryColumn, and new_table
has been created now, for testing.
When we try to get table schema for old_table
, for geometry column our query returns just geometry
as a datatype which is not enough to determine correct geometry type and CRS, while for new_table
we get proper datatype geometry(MultiPolygon, 25829)
.
As far as I can see this is related to changes in the system catalog between version 9 and supported recent releases.
I have a legacy PostgreSQL now in version 9.6 (PostGIS 2.5).
This database have been upgraded from previous versions and the old tables where created using
AddGeometryColumn
, so a\d
looks like this, with the check constraints present.In the copy process of mergin-db-sync an error is raised when processing these tables:
With new tables that does not have the check constraints it works correctly:
Not sure if this is a "bug" expected to be solved. Close it if you think that it is out of scope but it will be awesome if you have any advice or maybe a warning in the documentation can be added.