Re: Retiring support for pre-7.3 FK constraint triggers - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Retiring support for pre-7.3 FK constraint triggers
Date
Msg-id 20200305143041.GA7031@alvherre.pgsql
Whole thread Raw
In response to Retiring support for pre-7.3 FK constraint triggers  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Retiring support for pre-7.3 FK constraint triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)
Next
From: Robert Haas
Date:
Subject: Re: [Proposal] Global temporary tables