You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Breaking out standalone issue from #792, as this may need further review.
Basically, we double quote all field names in the sqlite plugin to ensure they don't conflict with reserved sql words and still work properly if they contain invalid characters. This seems like good practice and works great for the postgis plugin.
But it appears that if column names are double or single quoted and don't exist this prompts sqlite to silently coerce the field name reference to a string literal: https://gist.github.com/1435230
So for a table containing 2 rows a query like: select doesnotexist from table; returns 2 rows of results of simply the string doesnotexist. Insane!
Instead in Mapnik we wish for this to throw and be consistent with other datasources as per #792.
The text was updated successfully, but these errors were encountered:
Do not quote column names and deal with the fallout
Quote column names using either [] or "`", which are valid quoting mechanism in sqlite but which do not trigger coersion to string literals: http://www.sqlite.org/lang_keywords.html
Breaking out standalone issue from #792, as this may need further review.
Basically, we double quote all field names in the sqlite plugin to ensure they don't conflict with reserved sql words and still work properly if they contain invalid characters. This seems like good practice and works great for the postgis plugin.
But it appears that if column names are double or single quoted and don't exist this prompts sqlite to silently coerce the field name reference to a string literal: https://gist.github.com/1435230
So for a table containing 2 rows a query like:
select doesnotexist from table;
returns 2 rows of results of simply the stringdoesnotexist
. Insane!Instead in Mapnik we wish for this to throw and be consistent with other datasources as per #792.
The text was updated successfully, but these errors were encountered: