Re: pg_dump vs. TRANSFORMs
От | Tom Lane |
---|---|
Тема | Re: pg_dump vs. TRANSFORMs |
Дата | |
Msg-id | 15548.1462418615@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump vs. TRANSFORMs (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: pg_dump vs. TRANSFORMs
Re: pg_dump vs. TRANSFORMs |
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > 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. Actually, I believe it will be dumped. selectDumpableCast believes it should dump casts with OID >= FirstNormalObjectId. That's a kluge no doubt, but reasonably effective; looks like we've been doing that since 9.0. pg_dump appears not to have a special-case selectDumpableTransform routine. Instead it falls back on the generic selectDumpableObject for transforms. That's a bad idea because the only useful bit of knowledge selectDumpableObject has is to look at the containing namespace ... and transforms don't have one, just as casts don't. My recommendation is to clone that cast logic for transforms. regards, tom lane
В списке pgsql-hackers по дате отправления: