Paul Ramsey

I think this is useful but I'm +0 on the API. * Layer listing is good. * Need some way to play with connection strings to find one that works....

> How about: > > ```sql > ogr_fdw_info_server(ogr_datasource text, [...options]) returns text; -- CREATE SERVER... > ogr_fdw_info_table(server oid, layer text, [...options]) returns text; -- CREATE FOREIGN TABLE... > > ogr_fdw_info_layers(ogr_datasource...

> (I'll accept "it's still too confusing, don't do it" 😁 ) Nope I just have my head up my ass. Ignore me and procede.

I guess we must accept the server name as text...

Kinda stalled out. Almost there functionally I think? It's just less coolio than I had hoped ;)

I guess I was hoping to be able to address things as `regclass` rather than having to lookup names. You now, just seems yucky.

Perturb the inputs ever so slightly? Kind of like with buffer, there is a "close enough" aspect to the outputs of this operation.

Erm, maybe? Or maybe "match inputs" as an underlying expectatio? (maybe? I'm not wedded to this) should maybe unary union on multipolygon to return multipolygon?

So, that hole is about a nanometer wide. This kind of argues for ST_MakeClean, again, something to take "valid" geometries and remove ridiculous components like "holes that are less than...

In this case as well, I'd be interested to know if something like [GEOSIntersectionPrec()](http://libgeos.org/doxygen/geos__c_8h.html#a938f722bcb755689a2552bcbca3cf02b) helps. If you're running in PostGIS, the three-parameter version of [ST_Intersection()](https://postgis.net/docs/ST_Intersection.html). If the tolerance is big...