PostGIS Expression bug

[paalkr]

The new PostGIS support introduced a bug when using CLASSITEM and EXPRESSION. String comparison does not work, se the example below:

Does NOT work:

 LAYER
    ...
    CLASSITEM "maxhoyde"
    ...
    CLASS
       NAME "test"
       EXPRESSION "600"
       ...
     END
 END

Using RegEx instead WORKS:

 LAYER
    ...
    CLASSITEM "maxhoyde"
    ...
    CLASS
       NAME "test"
       EXPRESSION /600/
       ...
     END
 END

Using logical expression WORKS:

 LAYER
    ...
    #CLASSITEM "maxhoyde"
    ...
    CLASS
       NAME "test"
       EXPRESSION ([makshoyde] == 600)
       ...
     END
 END

[pramsey]

I tried to replicate this, but I can't: it works for me. Can you attach a table dump and map file please?

[paalkr]

Replying to pramsey:

I tried to replicate this, but I can't: it works for me. Can you attach a table dump and map file please?

Hi!

I have prepared a table dump and a mapfile, the zip archive is approx 1.6 MB so it's too large to attach, but can be download from ​| this link

[pramsey]

what should this test case generate? I am assuming that, if the bug is present, it should generate nothing, as none of the classes will match. However, I am getting a picture, which implies that it is still working on my installation, which is bad news, since it implies a more subtle bug than one might like, something related to platform.

[pramsey]

Nevermind, I see you have a catchall class at the end. Game on.

[pramsey]

Are you sure this ever worked in previous versions? I see an issue (the size is always returned as the field width (5) so the string values are things like "600 " and "1200 ", but that issue also exists in 5.2 and previous.

[pramsey]

Allow me to answer my own question. In previous versions the cursor was binary, so the records returned were probably null terminated at the end of the string. Now that I have a text cursor, things seem to have changed, and the null terminators are at the end of the *record*. I could strip trailing white space, but that may lead to other future problems...

[pramsey]

This should be "fixed" as of r8238, though I am not 100% comfortable with the fix at this moment. I am simply lopping off all the trailing spaces. This might be refined to only do so in cases where the field type is fixed width. Some experimentation will be needed to find the field types that exhibit the behavior of returning a fixed value for PQgetlength no matter how wide the actual data is.