Re: pg_dump versus views and opclasses

"Brendan Jurd" <direvus(at)gmail(dot)com> writes:
> On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Interesting --- it works as expected in 8.2. The problem seems to have
>> been created by the introduction of arrays over composites in 8.3.

> Congratulations on identifying the source!

I've applied a patch for this to HEAD and 8.3.

>> I'm thinking that adding operator family info to SortGroupClause in
>> HEAD might be a good thing too, but it is for a different issue than
>> this --- it's to prevent you dropping a family that a view has a
>> semantic dependency on. However there might be room for a bit of
>> argument there: if there's both a btree and a hash opfamily then
>> the view could use either, so preventing you dropping one would be
>> a bit arbitrary.

> Not to mention that, with the new default btree opclass in 8.4 that I
> stumbled across earlier, dropping an opclass that a view uses may not
> necessarily murder the view ... it may simply cause it to fall back to
> the default opclass. If falling back to the default opclass was
> actually what the user wanted to achieve by dropping the user-defined
> opclass, a dependency such as you describe might leave him with no way
> to do that.

> Worst case scenario is that you drop an opclass which causes a view to
> die, and next time you try to run the view you get an intelligible
> error message telling you why it doesn't work anymore. That's
> probably not the end of the world.

True. I'll leave well enough alone for the moment, unless someone
comes up with additional arguments.

regards, tom lane