> Is there a specific reason for the OGRPGTableLayer::BuildCopyFields (and > CreateFeatureViaCopy) checking that the field must exist in the layer > FieldDefn before adding it to the copy field list? Or is this a bug?
Jeremy, I've created http://trac.osgeo.org/gdal/ticket/4495 to capture the issue and pushed a fix. Note however that this area is a bit fragile since there are valid use cases where we don't want to impose the FID and let the DB do the autoincrement (*). The issue is that in COPY mode you must choose at the beginning if you will set or not the FID column for all the features to be copied. So the heuristics is now : if the first feature to be copied has a FID set, then we will also set it for all following features. Otherwise, if the first feature to be copied has no FID set, we will not set it and let the DB pick up a value for us for all the features. This is hopefully a reasonable assumption. I'm afraid I have no idea how to do it differently. But in INSERT mode, you can freely alternate features with FID set or unset. (*) I'm happy that we have a rich regression suite for the PG driver because my first attemps at fixing the 'new' use case initially broke those use cases. Best regards, Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
