Fix postgis_proc_set_search_path.pl to handle complex defaults quotes #515
Conversation
As discovered in postgis#514, an argument default with parenthesis instide the string breaks regression sql generator (evil regexes). Fixed with more evil regexes: now it has a special handling for a '...' -- ignoring all chars inside. Escaping is not handled (doesn't seem like PostGIS has any of them) Example: The script can now convert this: CREATE OR REPLACE FUNCTION ST_TileEnvelope(zoom integer, x integer, y integer, margin float8, bounds geometry DEFAULT 'SRID=3857;LINESTRING(-20037508.342789 -20037508.342789, 20037508.342789 20037508.342789)'::geometry) into this: ST_TileEnvelope(zoom integer, x integer, y integer, bounds geometry)
|
Hmm we were thinking of getting rid of postgis_proc_set_search_path.pl. It shouldn't be used for anything anymore -- you see it used somewhere. That was put in 2.2/2.3 days before we realized setting search path on functions kills performance. |
|
Regina, I'm all for making the build process more streamlined, but this is orthogonal to the bug at hand. At the moment, any change to |
I've created an issue to drop it: https://trac.osgeo.org/postgis/ticket/4579 I'll try to do it during the day so this PR will no longer be necessary. |
|
postgis_proc_set_search_path.pl removed |
As discovered in #514,
an argument default with parenthesis instide the string breaks
regression sql generator (evil regexes). Fixed with more evil regexes:
now it has a special handling for a '...' -- ignoring all chars inside.
Escaping is not handled (doesn't seem like PostGIS has any of them)
Example:
The script can now convert this:
CREATE OR REPLACE FUNCTION ST_TileEnvelope(zoom integer, x integer, y integer, margin float8, bounds geometry DEFAULT 'SRID=3857;LINESTRING(-20037508.342789 -20037508.342789, 20037508.342789 20037508.342789)'::geometry)
into this:
ST_TileEnvelope(zoom integer, x integer, y integer, bounds geometry)