* 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.



Attachment: signature.asc
Description: Digital signature

Reply via email to