I am going through the QGIS Training Manual (16.5.2) and could not figure out why the streets table throws a violation check error as trying to update a geometry column. I checked a very similar question at violates check constraint but couldn't get any clue. I understand "GeometryType" has been upgraded to "ST_GEOMETRYTYPE".
PostGIS – Check Constraint on Geometry Column Not Working as Expected
constraintpostgispostgresql
Best Answer
Look closely at both your
CHECK
constraint definition and the function docs:ST_GeometryType
returns the actual type (following theST_
prefix) formatted in PascalCase, i.e.ST_LineString
!You'd want to recreate that
CHECK
like so:However:
While you may get some insights in managing table
CONTRAINT
s following that tutorial, PostGIS type enforcing mechanisms have evolved significantly since it was written (which, apparently, was a looong time ago...), and by now the suggested table set-up violates best practices.The two PostGIS specific types
GEOMETRY
andGEOGRAPHY
allow for an explicit definition of the geometry type when used as column definition, as well as the SRID you want to enforce[¹] on your geometries, e.g. [²]:While in the early versions of PostGIS this was indeed realized by adding
CHECK
contraints during table creation, it now is implemented via the PostgreSQL type modificator system - an addition to core data types that allows direct enforcement of dynamic, type specific restrictions (see e.g.VARCHAR(50)
)The above set up follows current best practices, and has the intended behaviour - except that it also checks the SRID of the
INSERT
ed/UPDATE
ted geometries. In your case, since you use the EWKT string representation with attached SRID, it will just work.[¹]: enforce really means checked against: it will not do anything to solve issues - it just raises an error like yours
[²]: Note here that, except for
"name"
which is wrapped in"
, all other identifiers and SQL keywords are case insensitive, so the above is equivalent to