Re: pg_dump vs. TRANSFORMs - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pg_dump vs. TRANSFORMs
Date
Msg-id 20161207200915.GZ23417@tamriel.snowman.net
Whole thread Raw
In response to pg_dump vs. TRANSFORMs  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_dump vs. TRANSFORMs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
All,

* Stephen Frost (sfrost@snowman.net) wrote:
> While testing pg_dump, I discovered that there seems to be an issue when
> it comes to TRANSFORMs.

[...]

As pointed out by Peter E, this also impacts CASTs.  Attached is a patch
which addresses both by simply also pulling any functions which are
referenced from pg_cast or pg_transform when they have OIDs at or after
FirstNormalObjectId.  I also modified dumpCast() and dumpTransform() to
complain loudly if they're unable to dump out the cast or transform due
to not finding the function definition(s) necessary.

This'll need to be back-patched to 9.5 for the pg_transform look up and
all the way for pg_cast, though I don't expect that to be too difficult.

We don't do anything else with FirstNormalObjectId in SQL code in
pg_dump, though we obviously use it all over the place in the actual
code based on the OIDs returned from the database.  Still, does anyone
see an issue with using it in a query?  Without it, we end grabbing the
info for 100+ or so functions in a default install that we don't need,
which isn't horrible, but there were concerns raised before about
pg_dump performance for very small databases.

This also adds in regression tests to pg_dump for casts and transforms
and the pg_upgrade testing with the regression database will now
actually test the dump/restore of transforms (which it didn't previously
because the transforms weren't dumped).

Thoughts?

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Select works only when connected from login postgres
Next
From: Tom Lane
Date:
Subject: Re: Back-patch use of unnamed POSIX semaphores for Linux?