msPOSTGISLayerParseData locates primary key col

[phill.watson@…]

The function msPOSTGISLayerParseData() locates the primary key column if none 
specified with a "USING UNIQUE" expression in the DATA element. However, later 
functions (namely msPOSTGISLayerGetShape()) expect an OID column.

Also, bear in mind that the primary key may consist of multiple columns. 
Workaround - Comment out the following lines from the function 
msPOSTGISLayerParseData()

    if(!urid_found) {
      msPOSTGISLayerRetrievePK(layer, urid_name, *table_name, debug);
    }

[phill.watson@…]

Forgot to mention. Bug is caused, not because the other functions expect an OID 
specifically, but because they expect a numeric value. Fails only if the 
primary key is varchar column (or non-numeric).

[pramsey]

This is tricky indeed, because the internals of mapserver use a 'long' as a record identifier. So non-integral keys would have to be mapped into 'long' to fit into the mapserver internals. Multi-key primary keys have similar issues. We run into impedance at the level of the core mapserver structure.

BTW, 'oid' is now very deprecated, so 'working around' by going back to oid isn't an option anymore.

[pramsey]

The general improvement would be to reform the draw/query lifecycle in mapserver generally to reduce the dependence on unique keys for query resolution.

[pramsey]

I'm closing this because it is unlikely to be fixed unless there is more interest in the issue of non-numeric primary keys, or key-less operation of the driver. If there is enough interest to re-open the ticket, I will re-evaluate, but the reality is most people simple work around this issue by having a numeric key.