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 1me4Gr-0007Kj-TN for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Oct 2021 23:48:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1me4Gp-0007uE-TQ for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Oct 2021 23:48:19 +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 1me4Gp-0007tt-Lh for pgsql-hackers@lists.postgresql.org; Fri, 22 Oct 2021 23:48:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1me4Gn-0005sV-Be for pgsql-hackers@lists.postgresql.org; Fri, 22 Oct 2021 23:48:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 19MNmDIs2981075; Fri, 22 Oct 2021 19:48:13 -0400 From: Tom Lane To: Robert Haas cc: PostgreSQL Hackers , Andres Freund Subject: Re: pg_dump versus ancient server versions In-reply-to: References: <2923349.1634942313@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 22 Oct 2021 19:26:57 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2981073.1634946493.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2021 19:48:13 -0400 Message-ID: <2981074.1634946493@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > Another thing to think about in that regard: how likely is that > PostgreSQL 7.4 and PostgreSQL 15 both compile and run on the same > operating system? I suspect the answer is "not very." I seem to recall > Greg Stark trying to compile really old versions of PostgreSQL for a > conference talk some years ago, and he got back to a point where it > just became impossible to make work on modern toolchains even with a > decent amount of hackery. Right. The toolchains keep moving, even if the official language definition doesn't. For grins, I just checked out REL8_4_STABLE on my M1 Mac, and found that it only gets this far: checking test program... ok checking whether long int is 64 bits... no checking whether long long int is 64 bits... no configure: error: Cannot find a working 64-bit integer type. which turns out to be down to a configure-script issue we fixed some years ago, ie using exit() without a prototype: conftest.c:158:3: error: implicitly declaring library function 'exit' with= type\ 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-decla= ratio\ n] exit(! does_int64_work()); ^ I notice that the configure script is also selecting some warning switches that this compiler doesn't much like, plus it doesn't believe 2.6.x flex is usable. So that's *at least* three things that'd have to be hacked even to get to a successful configure run. Individually such issues are (usually) not very painful, but when you have to recreate all of them at once it's a daunting project. So if I had to rebuild 8.4 from scratch right now, I would not be a happy camper. That seems like a good argument for not deeming it to be something we still have to support. regards, tom lane