ogr sql can't see field named id in mysql database

[jef.mony@…]

ogrinfo -ro /root/sa_lo_bis.shp -sql "select * from
'MYSQL:lyon,user=root,port=3306'.lones"

this command retrieves all fields of the lones table, but this table has a field
named id, the primary key, wich is not listed.
I created a similar field named id_web wich is retrieves.
I tried with another table with filed named id, and the problem was the same.

[warmerdam]

Howard, 

I assume the problem is that id is being treated as the FID and stripped from
the conventional fields for the layer.

I think we may need to include the FID column in the regular attributes (as well
as using it for FID) unless it is named OGC_FID (or OGR_FID?), whatever our
OGR generated FID column is called. 

Does that make sense.

[kyngchaos@…]

>I think we may need to include the FID column in the regular attributes

Will this make it into the 1.3.2 release?  I'm trying to get a shapefile to mysql join to work, but it's not 
seeing the mysql id field because it thinks it's the FID.  I've tried renaming the field a variety of ways, but it 
still decides it's an FID (maybe due to primary key on an integer?).  I'm using the 2006/4/10 CVS 
snapshot.

[Even Rouault]

All those tickets have more than one year and nobody has acted on it, so the priority is not so high

[Jukka Rahkonen]

I am closing this ticket because it is not specific to MySQL. FIDs are not treated like ordinary fields but how, it depends on drivers. A simple workaround in this case is to use "SELECT id as id, * from...".

Maybe ogrinfo and ogr2ogr could have a general "-expose_fid" option that would copy the FID field into a normal attribute. If FIDs are exposed then they can also be edited which is usually a bad idea but perhaps GDAL users know what they are doing.