ALTER EXTENSION upgrade failing at ST_CurveToLine

[robe]

After I resolved the make install issue at #3916

this issue was uncovered on winnie

Preparing db 'postgis_reg' using: CREATE EXTENSION postgis
Upgrading PostGIS in 'postgis_reg' using: ALTER EXTENSION postgis UPDATE TO '2.5.0devnext'
Died at run_test.pl line 1423.
 failed (Error encountered altering EXTENSION POSTGIS: /projects/postgis/tmp/2.5.0dev_pg10_geos3.7.0dev_gdal2.2.2w64/regress_log)
-----------------------------------------------------------------------------
sh: createlang: command not found
CREATE EXTENSION
CREATE EXTENSION
ERROR:  cannot remove parameter defaults from existing function
HINT:  Use DROP FUNCTION st_curvetoline(geometry,double precision,integer,integer) first.

[robe]

Might be a winnie specific thing since I'm not getting same failure. Though I may not be running same upgrade tests.

[robe]

Ahah I see r16045 is the culprit. I think it's an accident that winnie was picking up on this though (though it is probably something that will be an issue upgrading from 2.4.* to 2.5, because you can't change default args without dropping old first)

[robe]

I think this is my bad. The postgis.sql scripts weren't being overwritten so copy issue since winnie copies her install scripts and I missed the postgis.sql one which is used when no version is specified and the file exists I think. So she might have been using an older one to install and next uses the right one.

I was able to upgrade from 2.4.0 to 2.5.0dev so still a little puzzeled why this owuld make a difference.

[robe]

In 16074:

revise winnie's regess and package script copying to edb install to copy over non-versioned .sql file as well.
references #3921

[robe]

In 16075:

revise winnie's regess and package script copying to edb install to copy over non-versioned .sql file as well.
Actually unversioned .sql aren't used at all, it was the next.sql scripts that weren't being overridden
references #3921

[strk]

Why are those scripts not just using make install ?

[robe]

It actually does use make install, but winnie has to test against another PostgreSQL instance (the VC++ build) so the install location is no good since it's the MingW PostgreSQL install location and since install location can't be controlled with —prefix, it's not really useful.

Also the installed items along with some other binaries (e.g. GDAL etc) need to be packaged in a zip file for windows users to consume.