[postgis-devel] Handling of new default arguments in upgrade procedure

[Sandro Santilli]

I came up with a solution for when views are defined to use functions
that we add new default arguments to. I love the solution in that
it only requires adding a comment above the function, like the
Available and Changed ones. It's a new comment, like this:

  -- Replaced: ST_Intersection(geometry, geometry) in 3.1.0

The upgrade procedure which sees that comment will do the following:

  1. Rename the old signature function name to <newname>
  2. Create the new signature
  3. REPLACE views (now) using the <newname> to make them use their
     original definition (now changed due to the rename in step 1)
  4. Drop the <newname> signature

I made the above work with the signature I've added a gridSize
parameter in 3.1.0, so now I can upgrade to 3.2.0dev from 3.1.3
and from 3.0.5 even in presence of views.

I did NOT handle materialized views, for which we will probably still
fail (but we could improve).

The reason why I'm writing this mail is because I'm not sure about
the syntax of the comment we want to write. In particular I'm not
sure if "Replaced" is specific enough, because the only thing we
actually handle here is a "backward-compatible API replacement",
while "Replaced" doesn't express any of that. Can you think of
a more clear label for that comment ?

References:

  The ticket reporting the problem:
  https://trac.osgeo.org/postgis/ticket/5033

  Staging PR which shows the failures (Dronie is probably the
  only bot currently testing upgrades from older versions):
  https://git.osgeo.org/gitea/postgis/postgis/pulls/66

  Copy of the PR on gitlab, which doesn't even notice
  the problem (bad bot!):
  https://gitlab.com/postgis/postgis/-/merge_requests/64
  

--strk; 

  Libre GIS consultant/developer
  https://strk.kbt.io/services.html