[postgis-tickets] [PostGIS] #4705: pgsql2shp - Pg field column in mapping file incorrectly compared with the name of the dbf field name

[PostGIS]

#4705: pgsql2shp - Pg field column in mapping file incorrectly compared with the
name of the dbf field name
----------------------------+-------------------
  Reporter:  zezzagio       |      Owner:  robe
      Type:  defect         |     Status:  new
  Priority:  medium         |  Milestone:
 Component:  loader/dumper  |    Version:  3.0.x
Resolution:                 |   Keywords:
----------------------------+-------------------

Comment (by zezzagio):

 I see no easy way to test this feature with the current test tool.

 If a <input>.shp.expected exists, the sub run_dumper_and_check_output is
 indeed called, without the -m parameter; and would fail (that's a start),
 if a .dbf.expected file was compared with the result, which is not. Only
 the .shp.expected is considered.

 The sub run_dumper_test is more promising, and seems to compare all the
 shape files. It is called if a ${TEST}.dmp file exists, from which it
 reads the parameters; but only as the last parameter of pgs1l2shp, that is
 the [table|query] argument. This goes after the [database] argument in the
 call, thus it can't be used to pass the -m option.

 Modifying run_dumper_test in order to take in account the custom options
 is not a big thing, of course, but I'm not very confident to be able to do
 it without breaking something.

 I can investigate further, if you want, and propose something. Not sure
 how much time it will take.

 I estimate that this bug is present al least from version 2.5 (possibly
 generated from some refactoring.) Having survived so long, I think, does
 mean this is not a very used feature (or maybe the 10 characters limit is
 not that low after all.) The whole shape file thing, I think, is something
 we have all been hoping for a long time to get rid of (perhaps the thing
 to do could be pgsl2spatalite or pgsql2gpkg.)

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4705#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.