Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cF6Qe-0000nM-2H for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2016 21:40:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cF6Qd-00053V-LO for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Dec 2016 21:40:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cF6Qc-00052d-Cc for pgsql-hackers@postgresql.org; Thu, 08 Dec 2016 21:40:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cF6QZ-0005Ab-Fg for pgsql-hackers@postgresql.org; Thu, 08 Dec 2016 21:40:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id uB8LeTCA008685; Thu, 8 Dec 2016 16:40:29 -0500 From: Tom Lane To: Stephen Frost cc: pgsql-hackers@postgresql.org Subject: Re: pg_dump vs. TRANSFORMs In-reply-to: <20161208204106.GI23417@tamriel.snowman.net> References: <20160504183952.GE10850@tamriel.snowman.net> <20161207200915.GZ23417@tamriel.snowman.net> <729.1481151371@sss.pgh.pa.us> <20161208142116.GC23417@tamriel.snowman.net> <4955.1481209396@sss.pgh.pa.us> <20161208204106.GI23417@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Thu, 08 Dec 2016 15:41:06 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8683.1481233229.1@sss.pgh.pa.us> Date: Thu, 08 Dec 2016 16:40:29 -0500 Message-ID: <8684.1481233229@sss.pgh.pa.us> X-Pg-Spam-Score: -4.9 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Stephen Frost writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> (Actually, the most likely way in which this would break things is if >> it started causing built-in casts to get dumped ... have you checked?) > So, this is fun. Apparently casts had OIDs > FirstNormalObjectId back > in 8.0 and earlier, so pg_dump >= 9.0 dumps out all casts which don't > have functions for server versions 7.3-8.0. Casts which do have a > function aren't included though, be they user-defined or not, because > they're excluded by getFuncs() and dumpCast() just punts. > With my change, pg_dump'ing against 8.0 and earlier will dump out all > casts, including those with functions, since the function definitions > will now be pulled in for them by getFuncs(). I poked into that, and you're right --- it wasn't until 8.1 (commit 2193a856a) that we had a hard-and-fast rule that initdb-assigned OIDs would be less than FirstNormalObjectId. Before that, the cutoff was variable and was recorded in pg_database.datlastsysoid. > What isn't clear to me is what to do about this. Given the lack of > anyone complaining, and that this would at least ensure that the > user-defined casts are dumped, we could just go with this change and > tell people who are dumping against 8.0 and earlier databases to ignore > the errors from the extra CREATE CAST commands (they shouldn't hurt > anything, after all) during the restore. There's a lot to be said for that. It dumped too much before, it'll dump a bit more now, but neither case is fatal. And it's unlikely that anybody really cares anymore. If you do want to do something about this, the way would be to retrieve datlastsysoid and use that as the cutoff with a pre-8.1 server. I think there used to be code to do things that way in pg_dump; we must have removed it (rather prematurely). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers