Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3722 closed defect (fixed)

ST_ASMVT regress on PostgreSQL 10

Reported by: robe Owned by: Björn Harrtell
Priority: medium Milestone: PostGIS 2.4.0
Component: postgis Version: master
Keywords: Cc:

Description

Bjorn,

I guess you can't easily check this until we have PostgreSQL 10 at least being able to compile PostGIS, as a result of #3271.

But here it goes, Debbie's last run in 10.0. MVT is just one of other problems with have with 10.0.

 mvt .. failed (diff expected obtained: /var/lib/jenkins/workspace/postgis/regress_pgdev/tmp/2_4_pg10.0w64/test_119_diff)
-----------------------------------------------------------------------------
--- mvt_expected	2017-02-06 16:48:10.479047203 +0000
+++ /var/lib/jenkins/workspace/postgis/regress_pgdev/tmp/2_4_pg10.0w64/test_119_out	2017-02-23 20:05:58.050464234 +0000
@@ -14,7 +14,7 @@
 TA4|GjAKBHRlc3QSDBICAAAYASIECTLePxIMEgIAARgBIgQJMt4/GgJjMSICIAEiAiACeAI=
 TA5|GiwKBHRlc3QSDhIEAAABARgBIgQJMt4/GgJjMRoCYzIiAiABIgYKBGFiY2R4Ag==
 TU1
-ERROR:  could not determine polymorphic type because input has type "unknown"
+ERROR:  could not determine polymorphic type because input has type unknown
 TU2
 ERROR:  pgis_asmvt_transfn: parameter row cannot be other than a rowtype
 TU3
-----------------------------------------------------------------------------

You might have even fixed this already. Can't tell till we fix up 10.0.

Change History (9)

comment:1 by robe, 8 years ago

Owner: changed from pramsey to Björn Harrtell

comment:2 by Björn Harrtell, 8 years ago

This looks like an error message from PostgreSQL that has slightly changed in version 10.

comment:3 by strk, 8 years ago

Ok this is tricky. In the past we used two _expected files and copied the appropriate one based on version (was done for GEOS). Annoying because then you have to remember to update both when adding new tests, but effective.

comment:4 by robe, 8 years ago

alternatively you could change the test to not error. I'm sure there is a perfectly good reason for triggering this error.

comment:5 by Björn Harrtell, 8 years ago

Yep it's a valid test for an expected error. I'll use the solution with two expected files if not too messy.

comment:6 by robe, 8 years ago

warning, I don't think we've ever done that on PostGIS. We usually just strip out the NOTICE content for example. I have no idea what strk is talking about about having done that with GEOS, though he's probably right. You are a very brave soul :)

comment:7 by Björn Harrtell, 8 years ago

Not that brave :) I thought it was for GEOS stuff in PostGIS. I'd rather find a solution without expanding on the regression test methodology. Can you point me to an example where you "strip out the NOTICE content"?

comment:8 by Björn Harrtell, 8 years ago

Resolution: fixed
Status: newclosed

In 15320:

Disable test that is too PG version specific
Fixes #3722

comment:9 by Björn Harrtell, 8 years ago

I opted to comment out this test as the error messages are intentionally changed in PG 10. Would need PL/pgSQL test runner to fix this to test against real error codes.

Relevant change in PostgreSQL is https://github.com/postgres/postgres/commit/9a34123bc315e55b33038464422ef1cd2b67dab2.

Note: See TracTickets for help on using tickets.