* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 5/4/16 11:23 PM, Tom Lane wrote: > >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. > > Hmm. The way I understand it is that Stephen wants to make dumping > that test case work. But note that that test case is bogus; it > wouldn't actually do anything useful in practice. There aren't any > functions in the system catalog that could be used for actual > transforms. So making these changes in pg_dump isn't really of much > practical value. Perhaps it would be easier to change the test case > or adjust the testing procedure?
I strongly disagree with the idea that this is only an issue with the testing system. What if we add functions in the future that are created by initdb and *are* useful for transforms? What about casts? There are a lot of functions in pg_catalog that a user might wish to use to define their own cast. This also doesn't do anything about users creating functions in pg_catalog. Thanks! Stephen
signature.asc
Description: Digital signature