The patch was reworked to be compliant with the published guidelines, documented and committed (revisions r6996, r7000, r7001) to the trunk by strk. Followups for the tickets (885 and 888) and the mailing list posts (tests and symbol map) were done.
astyle --style=ansi --indent=tab cunit/cu_tester.c cunit/cu_pgsql2shp.[ch] pgsql2shp-core.[ch] pgsql2shp-cli.c
it introduces a number of white space changes unrelated to the patch (mostly trailing white spaces). They are ignored during the patch generation with
svn diff -x --ignore-all-space loader
The new functions were documented using the doxygen conventions as follows:
/** * Read the content of filename into a symbol map stored * at state->geo_map. * * The content of the file is lines of two symbols separated by * a single white space and no trailing or leading space: * * VERYLONGSYMBOL SHORTONE\n * ANOTHERVERYLONGSYMBOL SHORTER\n * * etc. * * The file is read in core (one large malloc'd area), each * space and newline is replaced by a null character. A pointer * to the start of each line is stored in the state->geo_map * table. * * It is the reponsibility of the caller to reclaim the allocated space * as follows: * * free(*state->geo_map) to free the file content * free(state->geo_map) to free the pointer list * * @param filename : path to a readable map file in the format * described above. * @param state : container of state->geo_map where the malloc'd * symbol map will be stored. * * @return state->geo_map : NULL on error, symbol map pointer on * success. */
The usage lines for the -m flag contains a short explanation of the input map file format to be used as a reminder.
Remap identifiers to ten digit names.\n" " The content of the file is lines of two symbols separated by\n" " a single white space and no trailing or leading space:\n" " VERYLONGSYMBOL SHORTONE\n" " ANOTHERVERYLONGSYMBOL SHORTER\n" " etc.\n" ));
The introduction of tests for pgsql2shp post on the list and the associated patch were not answered. Since it is included in the larger patch, no followup was done. It was hoped that it would quickly make its way to the trunk because it is generally useful and does not imply the addition of a new functionality. The ticket was closed after the commited to the trunk by strk.
The post on the mailing list was not answered. A followup was sent together with a private mail to Vincent Picavet to ask for his advice on the best way to proceed.
There has been one question regarding the technical implementation of the patch. It was answered and the author ( nick strk ) was probed on irc.freenode.net#postgis but was not present at the time.