In answer to myself, quoting the offending columns (eg "2name") allows otherwise illegal column names to find their way to GDAL's filtering machinery.
Another question, which I seem to have an answer for: is "fid" a magic column name that will address the OGR fid? It seems to be, which is pretty amazing. What happens if an OGR table also has a legit field named "fid"? P On Thu, Apr 28, 2016 at 7:21 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote: > http://www.gdal.org/ogr__api_8h.html#a4000d426bf26ad7cc7d4012634c93f09 > > So, the reference to valid attribute filters points to > > http://ogdi.sourceforge.net/prop/6.2.CapabilitiesMetadata.html > > And there it says that > > @field_name@ = @string_token@ > > and that > > "The @string_token@ starts with a character in a-z,A-Z and is followed > by any number of characters in the set a-z,A-Z,0-9 and underscore." > > Now, OGR layer names can be quite a bit more complicated than that, > coming as they do from crazy data sources like FGDB, or even shape > file! So 'b-rthday' is a perfectly legal shape file attribute name, as > is 'Field Survey' from FGDB. > > How do we address those column names? > > I'm working in the FDW space, and have a mapping between PgSQL column > names (simple, not unlike the rule from the referenced document) to > OGR column names (crazy shit potentially). I figured I'd just re-write > the SQL to use the OGR names, and then boom, things would work, but it > turns out that OGR doesn't want to accept filters using the very > column names OGR has inside... so... what should we feed it? > > P _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
