From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pg_dump vs. TRANSFORMs
Date: Thu, 08 Dec 2016 16:40:29 -0500
Message-ID: <8684.1481233229@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Stephen Frost <sfrost@snowman.net> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, sfrost@snowman.net
Subject: Re: pg_dump vs. TRANSFORMs
In-Reply-To: <8684.1481233229@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox