[postgis-devel] Plan release PostGIS 3.4.0 this weekend

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

> Regarding the bin/postgis thing.  I've marked annotated this as a breaking
> change
>
> https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/NEWS#L68
>
> I think it was side effect of https://trac.osgeo.org/postgis/ticket/635 (yah
> took us 13 years to fix)

I am not complaining that it exists, just that I didn't figure it out
from NEWS, and my packager viewpoint is that if a new file shows up in
the package I should be able to tell from NEWS that this was intended.
It's ok now - thanks.

>> I did find that the (new?) bin/postgis:
>> 
>>   lacks a man page (I don't get any from build/install and don't see
>>   that I disabled them, but I am not passing --mandir either)
>> 
>>   is confusing, at least to me:
>> 
>
> Hmm this should have been fixed in the rc1 run, though I don't think Bas
> ever confirmed
> https://trac.osgeo.org/postgis/ticket/5447
>
> Maybe something different with BSD we are missing or it's not fixed.

I sent a separate note.  Doesn't seem BSD-specific; feels like just a
bug.

>> But install-extension-upgrades: I can't figure out that that means,
>> given that these files are installed by the default build.  So where
>> do they get installed *to*?  And if they aren't installed already, I
>> don't know where they come from, because at runtime, the source is no
>> longer available.
>
> There is an option to not install it, but we went with installing by default
> to not cause a breaking change.
>
> I think this is only useful for people building their own postgis who want
> to cherry pick the paths to install.
> Remember Sandro tried to explain how this could be useful for packagers.  I
> didn't get it. I don't think you did either.

Now it's coming back to me.

As a packager I don't see how this is useful, because when somebody
installs the package, I have no idea what they used to have, so there's
no basis to leave things out.  And, when someone uses the package, the
build tree isn't present, so there's no source for the wanted files.

So maybe the text should say:

  Postgis normally installs a full set of upgrade scripts, so that
  arbitrary previous installations can be upgraded.  If postgis was
  configured not to install the full set, and the build directory is
  present, one can use this command to install specific files.

and clean up references to "share directories" which IMHO are to bits
installed in the system, not dirs in the sources.

If this is "only install some upgrade scripts", that's part of make
install, not part of an installed utility that needs the sources, so I
find this all irregular.

However, my real goal today is to unconfuse people who might think they
need this, as users of binary packages will ~never need it.

>> postgis_restore's help does not seem to use the new 'postgis' command.
>> Which points out that the new command doesn't seem to work with
>> extensions.
>> 
> postgis_restore is mostly useful for people who are coming from a
> non-extension install.

The help doesn't say that, or point to other docs.

> Hopefully there aren't too many of those left.  It's been there since the
> 1.0 days though it has gone under
> many improvements in that time.
>
> If you installed PostGIS with CREATE EXTENSION using pg_restore is usually
> sufficient.

I didn't figure that out from the help (and without a man page handy :-)

> The main thing that postgis_restore did apart from pg_restore, is filtering
> out obsolete functions
> and I think taking care of SRID issues that were not within range. 

The man page is much better.  I would suggest removing the mini-howto
from the usage, and ensuring the man page is right.

The man page should also start out with what it does/is-useful for, so
that people that are unclear will be led to clarity more quickly.

----------------------------------------
postgis_restore is a helper script to restore dumps of postgis-enabled
databases only in the case were those in which PostGIS was enabled by
loading the postgis.sql script.

Dumps taken from databases in which PostGIS was enabled via CREATE
EXTENSION will contain CREATE EXTENSION, and will not have PostGIS
objects in them.  They can therefore be restored directly using
pg_restore, and postgis_restore should not be used.

[Explain if postgis_restore detects CREATE EXTENSION and errors out if
so.  Explain if postgis_restore detects if "custom" format was not used
and errors out if so.]

[and then paragraphs 1/3, and example, pointing out that the example
also includes migration to the "CREATE EXTENSION" flavor]