LAYER BINDVALS

[geographika]

In the layerObj declaration there is a hashTableObj bindvals; variable. It also appears to be a valid Mapfile keyword and appears in several places in the codebase - https://github.com/MapServer/MapServer/search?q=bindvals&type=code including a unit test:

MapServer/msautotest/mspython/test_postgis.py

Line 247 in 2bc7f62

BINDVALS

It appears related to https://mapserver.org/development/rfc/ms-rfc-59.html - however this has a status of Not Adopted.

Does anyone know if this a missing keyword on the LAYER page, or a forgotten keyword? I'd assume the former as it has a test that is passing.

[jmckenna]

@theduckylittle does this ring a bell?

[theduckylittle]

Sure does! Not sure where the RFC voting history is or what the ultimate concerns were regarding the implementation. It does look like the code made its way into the Github repo. The intent of BINDVALS is to prevent SQL injection. It would actually be good if there were implementations for the rest of the SQL-based drivers.

I should also PR to update my email address! Ha!

[geographika]

@theduckylittle - thanks for getting back. Have you been using this feature in live systems since it was implemented? Is it stable enough in your view to add to the docs as a feature?

I'm not sure if BINDVALS came before or after VALIDATION blocks, but is there an overlap between them?
Would the following produce the same result/approach?

DATA "select count(*) from parcels where city_id = :%city_id%
VALIDATION
    "city_id" "1"
END

I had a look into bind parameters for SQL Server and there is no exact equivalent, SQL would need to be run through sp_executesql, although this approach could reduce memory usage.

Relevant mailing list post from when the RFC was introduced: http://osgeo-org.1560.x6.nabble.com/RFC-59-td4257517.html

[jmckenna]

I think this can be closed now. Thanks both @theduckylittle & @geographika !!