"Brendan Jurd" <dire...@gmail.com> writes:
> On Sun, Jan 18, 2009 at 5:56 AM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
