RE: [PATCH] Support % wildcard in extension upgrade filenames - Mailing list pgsql-hackers

From Regina Obe
Subject RE: [PATCH] Support % wildcard in extension upgrade filenames
Date
Msg-id 007901d96cc3$a543b240$efcb16c0$@pcorp.us
Whole thread Raw
In response to Re: [PATCH] Support % wildcard in extension upgrade filenames  (Sandro Santilli <strk@kbt.io>)
List pgsql-hackers
> Personally I don't see the benefit of 1 big file vs. many 0-length files
to justify
> the cost (time and complexity) of a PostgreSQL change, with the
> corresponding cost of making use of this new functionality based on
> PostgreSQL version.
> 
From a  packaging stand-point 1 big file is better than tons of 0-length
files.  
Fewer files to uninstall and to double check when testing.

As to the added complexity agree it's more but in my mind worth it if we
could get rid of this mountain of files.
But my vote would be the wild-card solution as I think it would serve more
than just postgis need.
Any project that rarely does anything but  add, remove, or modify functions
doesn't really need multiple upgrade scripts and 
I think quite a few extensions fall in that boat.

> We'd still have the problem of missing upgrade paths unless we release a
new
> version of PostGIS even if it's ONLY for the sake of updating that 1 big
file (or
> adding a new file, in the current situation).
> 
> --strk;

I think we always have more releases with newer stable versions than older
stable versions.
I can't remember a case when we had this ONLY issue.
If there is one fix in an older stable, version we usually wait for several
more before bothering with a release 
and then all the stables are released around the same time.  So I don't see
the ONLY being a real problem.






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR messages in VACUUM's PARALLEL option
Next
From: Andres Freund
Date:
Subject: Re: When to drop src/tools/msvc support