> I wonder if a solution to this problem might be to provide some kind of a
> version map file. Let's suppose that the map file is a bunch of lines of the form
> X Y Z, where X, Y, and Z are version numbers. The semantics could be: we (the
> extension authors) promise that if you want to upgrade from X to Z, it suffices
> to run the script that knows how to upgrade from Y to Z. This would address
> Tom's concern, because if you write a master upgrade script, you have to
> explicitly declare the versions to which it applies. But it gives you a way to do
> that which does not require creating a bazillion empty files. Instead you can
> just declare that if you're running the upgrade script from
> 14.36.279 to 14.36.280, that also suffices for an upgrade from
> 14.36.278 or 14.36.277 or 14.36.276 or ....
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
That's what I was proposing as a compromise.
Just not sure what the appropriate name would be for the map file.
Originally I thought maybe we could put it in the .control, but decided
it's better to have as a separate file that way we don't need to change the control and just add this extra file for
PostgreSQL16+.
Then question arises if you have such a map file and you have files as well (the old way).
Would we meld the two, so the map file would be used to simulate the file paths and these get added on as extra target
pathsor should we just assume if there is a map file, then that takes precedence over any paths inferred by files in
thesystem.
Thanks,
Regina