<div dir="ltr">QGIS' expression engine has two string functions – substr() and strpos() – using two distinct character count standards. The substr() character count begins with 1, as per the equivalent postgresql string function. The strpos() character count however begins with 0, as per Qt / python's equivalent string function.<br><br>This is a pretty ugly state of affairs as one expects those two functions to rely on the same character count method. <br><br>For .e.g, here's a practical example: the expression substr('1234;1234',0,strpos('1234;1234',';')) would – in QGIS – return '123' because of the character count discrepancy between the two functions. That's very, very ugly and counter-intuitive.<br><br>IMHO, substr()'s adherence to postgresql is the right way to go in the context of QGIS expressions, which means addressing this issue would mean fixing strpos() so its count starts at 1.<br><br>Now, the question is, should – and if so how – we address this yuckiness. Should we leave things as it is, and add a note in the documentation about the discrepancy? Or should we fix strpos() acknowledging the longer we wait the harder it'll be, and make sure the changelog has a big bright note for users to know a fix has been applied?<br><br>Awaiting opinions.<br><br>Mathieu<br></div>