From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_trgm version 1.2 |
Date: | 2015-06-30 22:10:10 |
Message-ID: | 3921.1435702210@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Tue, Jun 30, 2015 at 2:46 AM, Alexander Korotkov <
> a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>> pg_trgm--1.1.sql andpg_trgm--1.1--1.2.sql are useful for debug, but do you
>> expect them in final commit? As I can see in other contribs we have only
>> last version and upgrade scripts.
> I did see another downgrade path for different module, but on closer
> inspection it was one that I wrote while trying to analyze that module, and
> then never removed. I have no objection to removing pg_trgm--1.2--1.1.sql
> before the commit, but I don't see what we gain by doing so. If a
> downgrade is feasible and has been tested, why not include it?
Because we don't want to support 1.1 anymore once 1.2 exists. You're
supposing that just because you wrote the downgrade script and think
it works, there's no further costs associated with having that.
Personally, I don't even want to review such a script, let alone document
its existence and why someone might want to use it, let alone support 1.1
into the far future.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-30 22:15:50 | Re: Solaris testers wanted for strxfrm() behavior |
Previous Message | Josh Berkus | 2015-06-30 21:51:31 | Re: Solaris testers wanted for strxfrm() behavior |