Date: Thu, 5 Mar 2020 11:30:41 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Retiring support for pre-7.3 FK constraint triggers
Message-ID: <20200305143041.GA7031@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <805874E2-999C-4CDA-856F-1AFBD9DFE933@yesql.se>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Mar-05, Daniel Gustafsson wrote:

> While looking at the tg_updatedcols patch I happened to notice that we still
> support pre-7.3 constraint triggers by converting them on the fly.  AFAICT this
> requires a pre-7.3 dump to hit.
> 
> This was added in late 2007 in a2899ebdc28080eab0f4bb0b8a5f30aa7bb31a89 due to
> a report from the field, but I doubt this codepath is excercised much today (if
> at all).

pg_dump's support for server versions prior to 8.0 was removed by commit
64f3524e2c8d (Oct 2016) so it seems fair to remove this too.  If people
need to upgrade from anything older than 7.3, they can do an intermediate jump.

> Having code which is untested and not excercised by developers (or users, if my
> assumption holds), yet being reachable by SQL, runs the risk of introducing
> subtle bugs.  Is there a usecase for keeping it, or can/should it be removed in
> 14?  That would still leave a lot of supported versions to upgrade to in case
> there are users to need this.  Unless there are immediate -1's, I'll park this
> in a CF for v14.

I know it's a late in the cycle for patches in commitfest, but why not
consider this for pg13 nonetheless?  It seems simple enough.  Also, per
https://coverage.postgresql.org/src/backend/commands/trigger.c.gcov.html
this is the only large chunk of uncovered code in commands/trigger.c.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services