Re: pg_dump vs. TRANSFORMs

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump vs. TRANSFORMs
Date: 2016-05-04 21:00:54
Message-ID: 20160504210054.GH10850@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 5/4/16 2:39 PM, Stephen Frost wrote:
> >These checks are looking for the functions used by the transform in the
> >list of functions that pg_dump has loaded, but in 9.5, we don't load any
> >of the function in pg_catalog, and even with my patches, we only dump
> >the functions in pg_catalog that have an ACL which has been changed from
> >the default.
>
> This issue is not specific to transforms. For example, if you
> create a user-defined cast using a built-in function, the cast won't
> be dumped. Obviously, this is a problem, but it needs a more general
> solution.

Ah, I hadn't gotten to casts yet with my test framework.

I'm certainly open to suggestions on how to address this, but I will
point out that we already have a number of cases where we issue
additional queries against the database from the dump*() functions when
we need to collect additional information. That's not wonderful because
it ends up being slow, but it does work.

Trying to figure out what functions we need at getFuncs() time isn't
terribly easy. On the other hand, it might not be *that* bad to just
pull in all functions, if we use the same technique that we use for
tables, and mark the ones we aren't dumping as not "interesting."

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-05-04 21:02:04 Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Previous Message Jeff Janes 2016-05-04 21:00:01 Re: atomic pin/unpin causing errors