Clarify use of PG variables used by loader_generate_script

[beland]

One of the steps in setting up the TIGER geocoder is to run, for example:

SELECT loader_generate_script(ARRAYMA, 'sh') AS result;

The resulting script is buggy: it does not respect several of the configuration steps at the top, and some lines refer to non-existent files. I'm attaching a version with suggested fixes.

I am running postgis2_93-2.1.1-1.rhel6.x86_64 on CentOS 6.

[robe]

What non-existent files does it refer to?

What configuration steps at the top does it not respect. It looks like you defined your own. e.g. I don't recall there being a variable called DOWNLOADDIR.

[beland]

Actually, I think what I uploaded was derived from the wrong function; I'll fix that shortly.

The first item that is not respected properly is:

TMPDIR="/gisdata/temp/"

At the end of the first section there is:

cd /gisdata

The problem is that if you change TMPDIR, to say /home/beland/gisdata/temp, because /gisdata doesn't exist, the hard-coded references still point to /gisdata.

So what the script needs is something like $DOWNLOADDIR, and to define $TMPDIR=$DOWNLOADDIR/tmp. Or, change the meaning of TMPDIR to be what I call DOWNLOADDIR.

The second group of non-respected config variables are PGPORT, PGHOST, PGUSER, PGPASSWORD, and PGDATABASE. These are all defined but never used in the script.

I'm using local sockets, for example, so I don't actually want to have a PGHOST, so it made sense to me to just let the user define their own $PSQL command-line arguments. Or you could keep the PGXXXX variables and actually use them in the definition of $PSQL.

As for the non-existent files, there are often two "for" lines right next to each other, like:

for z in tl_*_25*_place.zip ; do $UNZIPTOOL -o -d $TMPDIR $z; done for z in */tl_*_25*_place.zip ; do $UNZIPTOOL -o -d $TMPDIR $z; done

The second pattern, */tl_*_25*_place.zip, does not match anything downloaded by the wget. There are */ variants in each of these pairs, and so far it seems they always produce an error. When cleaning up these scripts here, we just deleted the second lines and we still got the geocoding system to work, so I guess they aren't necessary.

[beland]

Oh, I see the PGXXXX variables are exported; maybe psql looks at them as environment variables? I suppose that works, though it is a bit confusing. Maybe worth a comment.

[robe]

Yah I can link to the documentation on the PostgreSQL website for that. I'll add to readme.

For reference they are all defined here:

​http://www.postgresql.org/docs/9.3/static/libpq-envars.html

[robe]

changing this to a documentation task

[komzpa]

In 16652:

Clarify that PG* variables are used by psql directly.

Closes #2628