Fix postgis_restore.pl to upgrade from PostGIS installed in a dedicated schema

[frost242]

Hello,

One of our customers has PostGIS installed a dedicated schema in his database. We had to fix postgis_restore.pl to get rid of multiple errors during the restore.

You can find an attached patch to postgis_restore.pl to add a new option -s schemaname to be able to tell the script in witch schema is PostGIS located.

It may need some rework, but at least it works for our client.

Regards, Thomas

[frost242]

Patch to add -s schemaname to postgis_restore.pl

[strk]

I don't trust those "SET search_schema" statements. Would have no problem if absence of -s switch would omit those lines.

[frost242]

patch updated per comments.

[frost242]

Please find an updated version of this patch to address your comment. The schema name is also now protected by double-quotes.

Regards, Thomas Reiss

[strk]

A couple more tweaks:

• It is postgis_restore.pl.in that needs to be patched
• Please avoid introducing a dependency on GetoptLong, isn't really needed in this case

[frost242]

Sorry, I missed to patch the appropriate file.

About GetOpt::Long, do you mean to avoid using any helper module and parse @ARGV or is it possible to rely on the lighter GetOpt::Std ?

[strk]

I mean to parse @ARGV directly, like it's done for -v, while shift() check what it is

[frost242]

Another revision of the patch

[frost242]

Comments adressed in the attached patch.

I used the same construct as for -v, that means the options must be passed in a defined order: -v always before -s. I hope it's OK this way.

[strk]

Better, I improved the option parsing so you can specify in arbitrary order as long as it is before the dump filename. It's in trunk @ r11285

[strk]

Actually I'm reopening because the code still lacks adding -s semantic to Usage output (see bottom line of the output, it tells you about -v but not about -s).

A note in the manual may also be nice to have.

Actually I'm also unclear myself about what the switch does. It looks like restoring into a database in which postgis is installed in a custom schema, is that correct ? But how does it deal with a _dump_ having postgis in a custom schema ? Is it still able to drop that one ?

[strk]

r11296 adds to usage string. Will not touch the postgis manual as this new switch seems partial to me (some of the signatures to be skipped from the dump have "public" schema name hard-coded, thus restoring a dump in which postgis is in a separate schema would fail to skip those functions, even with the -s switch).

Anyway, considering this complete.

[frost242]

Thanks !