fixing issue with PostGIS topology extension

[lwiechec]

environment variable DB_POSTGIS_TOPOLOGY controls creation of
'postgis_topology' extension only when user selects PostGIS extension.

refs #44

[lwiechec]

Hi Sameer,

sorry for creating another pull request but I am not sure how to 'fix' the existing one (and I have a very poor Internet connection right now).

[lwiechec]

                                                                                  Thanks!                                                                                                                                                                                                                                                                                                                                         Łukasz Wiecheć                                                                                                                                                                                                                 From: Sameer NaikSent: Monday, 11 January 2016 18:00To: sameersbn/docker-postgresqlReply To: sameersbn/docker-postgresqlCc: Lukasz WiechecSubject: Re: [docker-postgresql] fixing issue with PostGIS topology extension (#47)Merged #47.

—Reply to this email directly or view it on GitHub.

[sameersbn]

I am concerned about the upgrade path to take when the PostGIS version is updated. Right now it looks like the user will manually need to update as per these instructions http://postgis.net/docs/manual-2.1/postgis_installation.html#soft_upgrade_extensions.

Is there is way that we can detect that a particular database is running an older version of the extension and upgrade it automatically?

Or is this a bad idea and we should leave this to user which would mean that the user will need to keep a watch on the changelog of the image? In which case it might make sense to remove the PG_POSTGIS and other such variables and leave it up to the user to enable extensions manually using the psql cli. In this case we only package the extension with the image, activating/upgrading is left to the user.

My ultimate aim is to have minimal support requests.

edit: one question I had was that I see PostGIS 2.2 is available. Any particular reason you chose 2.1?

[lwiechec]

Hi Sameer,

I think you are right with assuming that upgrading the PostGIS database
is not a trivial thing. I personally never had to do it, though; that's
why it didn't even go through my head.

There is a way to get the version of the PostGIS from the spatial-enabled
database, you do 'select postgis_lib_version()';. On my 'csd' the database that
runs from your Docker image, I get this:

csd=# select postgis_lib_version();

postgis_lib_version

2.1.8
(1 row)

But even with this, the PostGIS manual is very clear: the data might be
lost, so the best is to dump/import it.

For me it would be great if I could have a quick way to start Docker
containerized PostgreSQL + PostGIS but maybe, from maintainability
perspective, it makes more sense to use 'psql' tool...

Cheers,

Łukasz Wiecheć

Sameer Naik writes:

I am concerned about the upgrade path to take when the PostGIS version
is updated. Right now it looks like the user will manually need to
update as per these instructions
http://postgis.net/docs/manual-2.1/postgis_installation.html#soft_upgrade_extensions.

Is there is way that we can detect that a particular database is
running an older version of the extension and upgrade it
automatically?

Or is this a bad idea and we should leave this to user which would
mean that the user will need to keep a watch on the changelog of the
image? In which case it might make sense to remove the PG_POSTGIS and
other such variables and leave it up to the user to enable extensions
manually using the psql cli. In this case we only package the
extension with the image, activating/upgrading is left to the user.

My ultimate aim is to have minimal support requests.

—
Reply to this email directly or view it on GitHub.