Remove unneeded the_geom_webmercator param from ST_AsMVT

[rafatower]

That parameter is not needed. As per the documentation:

geom_name is the name of the geometry column in the row
data. Default is the first geometry column.

This will let us push-down the whole ST_AsMVT expression to foreign
servers through FDW's.

[Algunenano]

This will let us push-down the whole ST_AsMVT expression to foreign
servers through FDW's.

Can you explain why, both here and in the code itself so we keep that information for future changes?

[rafatower]

I just noticed this is a partial solution to a wider problem. When trying to push-down the ST_AsMVT to the remote end, I was getting this from the foreign end:

ERROR:  parse_column_keys: no geometry column found

The root cause is that, at some point in the process, the query is replacing column/field names by arbitrary f1, f2, ... aliases. When the foreign end checks for that geometry column and does not really find any column matching the_geom_webmercator, it fails.

But patching that yields to other problems down the line: as the column/field names are changed, the client cannot really process the obtained MVT. This is how it may look through vt2geojson:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [
            -122.38100051879883,
            37.735969208590504
          ],
          [
            -122.38065719604492,
            37.7355619376922
          ],
          [
            -122.38027095794678,
            37.73535830140294
          ],
          [
            -122.3798418045044,
            37.73525648304823
          ],
          [
            -122.37941265106201,
            37.73525648304823
          ]
        ]
      },
      "properties": {
        "f2": "RD",
        "f3": 5
      }
    },
//...

instead of the expected:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [
            -122.39580631256104,
            37.78835270558375
          ],
          [
            -122.39546298980713,
            37.78808138412046
          ]
        ]
      },
      "properties": {
        "st_type": "ST",
        "cartodb_id": 238
      }
    },
//...

so, let's put this on hold, and hopefully I'll find a way that avoids it altogether.

[rafatower]

thanks!

[rafatower]

The root cause of this is an issue with type checking, FDW's and search paths, apparently fixed in recent versions of postgis: postgis/postgis@e096795#diff-86bc92dfea8fd30b975e278bd323067f

In order to increase compatibility with other postgis install, we need this patch.

[rafatower]

For the record, the problem with column names / attributes is dealt with here: CartoDB/postgres#25

[Algunenano]

In order to increase compatibility with other postgis install, we need this patch.

Go ahead, but in my opinion this isn't fixing the problem in the proper place.