OGR SQL: confusion between literal that is equal to a column name

[nirvn]

I've just hit a really strange bug. Using the attached shapefile, OGR Shapefile driver is unable to query the dataset using a simple string attribute filter and return "error 1: type mismatch or improper type of arguments to = operator".

Steps to reproduce:

1. Use the following ogrinfo command line on the attached shapefile:

ogrinfo -al -where "PARTY_1ST = 'CPP'" "election 2012\commune_election_results_v2.shp"

This will fail, returning error 1

2. Use the following ogrinfo command line on the attached shapefile:

ogrinfo -al -where "PARTY_1ST = 'HRP'" "election 2012\commune_election_results_v2.shp"

This will fail, returning error 1

2. Use the following ogrinfo command line on the attached shapefile:

ogrinfo -al -where "PARTY_1ST = 'Sam Rainsy'" "election 2012\commune_election_results_v2.shp"

This will work and list the filtered features.

[nirvn]

Oups, turns out the shapefile is over attachment's size limit. I've uploaded the shapefile to this location: ​http://licadho-cambodia.org/gdal/Election2012.zip

[Even Rouault]

Hum, the issue here is that the OGR SQL engine confuses the 'CPP' litteral and the CPP column. This is indeed a known issue listed in paragraph 'More stricter OGR SQL syntax to distinguish literals from identifiers' of http://trac.osgeo.org/gdal/wiki/GDAL20Changes.

One way of workarounding this for wnow is to ogr2ogr your shapefile to sqlite and then issue the request on the sqlite file.

[Even Rouault]

Has been implement per http://trac.osgeo.org/gdal/wiki/rfc52_strict_sql_quoting

[Even Rouault]

Milestone renamed