Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nuhe3-0003Dk-Nl for pgsql-hackers@arkaria.postgresql.org; Fri, 27 May 2022 21:37:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nuhe2-00024o-Je for pgsql-hackers@arkaria.postgresql.org; Fri, 27 May 2022 21:37:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nuhe2-00024b-79 for pgsql-hackers@lists.postgresql.org; Fri, 27 May 2022 21:37:18 +0000 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nuhdz-0000xW-E5 for pgsql-hackers@postgresql.org; Fri, 27 May 2022 21:37:17 +0000 Received: by mail-qk1-x730.google.com with SMTP id j6so6274752qkp.9 for ; Fri, 27 May 2022 14:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pcorp-us.20210112.gappssmtp.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=VZgKyGk+P7zLgk21sNZwmVN/D8zCnK2Ceify+DvVDTA=; b=gQHL7wEBrCzYHvpp9Q+K+vQI7w7XVR+5o/uRty9RPhvpuzD7lXjuVS4Fd1Crtv5TsI BAsJJOpe7xtx+L+Kpzkk5gzk/doMCAAnzEQoaNNbFPTj5WYvbDAh12Fe4akNzMeQqp0X RhKTx17vDNdGYKmj8YxpZH35JDcgYh54q/+x2RKogCUMh46CO6g3vu2PlhGXdRK8Dtim VYIz4PUTNTm/zegSP3Ht+Votao/FgtZoHu6IzJGH9wZ6FdU3riH1T7w2GLwTY7MClCAp 2thSvr/cPYVcouoGF+3AVhJQLmoH5b0mPTt1uPaWJv/F32rQlfkJ/+OcR8GXshKli7/p su4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=VZgKyGk+P7zLgk21sNZwmVN/D8zCnK2Ceify+DvVDTA=; b=2ys0jSU/0O9r6bVDhvq63d+zlajuWpNTPouchqAtMrjb04Uvlsu7kN/kMOK2XBOhYF YI2A7aAhiuYZJhqTvgkaa+DnXCnS1XOfLKqigE7cqjEL0JUEQUNgdu0xV6ZECe78epRG jptWc7/QWCxr/pHOS0+HL4RRl8OtHN+KSGClrPVt2ztm1XMBqWnk3Ch7LdzbNgqLTGPw WiPrR5Wy/dYt0wF9ePq+lvHQH4ROoruxyf//vm8VuHFKe+qc9tjl7pu4r+20R23Cg/Sp acdXR4vbc/LxBiDGvdjTLs+KWZE0yOnaAxz3w/3ZYTX37TFzlQhdpWEbVsjKDfUpH0o1 m1Mw== X-Gm-Message-State: AOAM530Mux2AJZKSJhE5W/bfpl3q5Cs6Dffe50bl6jhNMOp5hk+VB8OQ hUtZmKBcD6MgJbTd/XZfKAD7dO80U/RTfw== X-Google-Smtp-Source: ABdhPJzD68gBwKcNGxnZ5wTB1tcPuDyVlm94ePoV+UrpLQzF93YqMJiD7fwk/sR3L0SoalgMVb2E9w== X-Received: by 2002:a37:62cd:0:b0:6a3:4cbe:e74e with SMTP id w196-20020a3762cd000000b006a34cbee74emr25212809qkb.550.1653687434395; Fri, 27 May 2022 14:37:14 -0700 (PDT) Received: from F (50-78-240-110-static.hfc.comcastbusiness.net. [50.78.240.110]) by smtp.gmail.com with ESMTPSA id q2-20020a378e02000000b0069fcabfdaebsm3369768qkd.70.2022.05.27.14.37.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 May 2022 14:37:13 -0700 (PDT) From: "Regina Obe" To: , References: In-Reply-To: Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames Date: Fri, 27 May 2022 17:37:12 -0400 Message-ID: <001d01d87211$edbd5b50$c93811f0$@pcorp.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGYmaaUCwtlrmE55CHyCSUXu9VHkq2y7tow Content-Language: en-us List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > At PostGIS we've been thinking of ways to have better support, from > PostgreSQL proper, to our upgrade strategy, which has always consisted in a > SINGLE upgrade file good for upgrading from any older version. > > The current lack of such support for EXTENSIONs forced us to install a lot of > files on disk and we'd like to stop doing that at some point in the future. > > The proposal is to support wildcards for versions encoded in the filename so > that (for our case) a single wildcard could match "any version". I've been > thinking about the '%' character for that, to resemble the wildcard used for > LIKE. > > Here's the proposal: > https://lists.osgeo.org/pipermail/postgis-devel/2022-February/029500.html > > A very very short (and untested) patch which might (or might not) support our > case is attached. > > The only problem with my proposal/patch would be the presence, on the wild, > of PostgreSQL EXTENSION actually using the '%' character in their version > strings, which is currently considered legit by PostgreSQL. > > How do you feel about the proposal (which is wider than the patch) ? > > --strk; > > Libre GIS consultant/developer > https://strk.kbt.io/services.html [Regina Obe] Just a heads up about the above, Sandro has added it as a commitfest item which hopefully we can polish in time for PG16. https://commitfest.postgresql.org/38/3654/ Does anyone think this is such a horrible idea that we should abandon all hope? The main impetus is that many extensions (postgis, pgRouting, and I'm sure others) have over 300 extensions script files that are exactly the same. We'd like to reduce this footprint significantly. strk said the patch is crappy so don't look at it just yet. We'll work on polishing it. I'll review and provide docs for it. Thanks, Regina