On Wed, Oct 26 2022, Taylor Blau wrote: > On Mon, Aug 29, 2022 at 10:48:03AM +0800, Teng Long wrote: >> > If the "ignoring extra" is a totally expected situation (e.g. it is >> > not suprising if we always ignore the bitmapfile in the alternate >> > when we have our own), perhaps we should squelch the warning in such >> > expected cases altogether (while warning other cases where we see >> > more bitmap files than we expect to see, which may be an anomaly >> > worth warning about), and that may be an improvement worth spending >> > development cycles on, but I am not sure about this one. >> >> That's exactly good suggestion. In my opinion, I think to avoid the sensitive >> warning and the same time we keep some information to let the users know "Oh, >> there are some extra existing bitmaps we just ignored then maybe can do some >> optimization works", but I think just remove the total warning here is >> reasonable also, i'm good with it. > > I think that it is somewhat of a step backwards to remove it entirely, > but let me qualify that a little bit. > > At GitHub, we actually *do* remove this warning entirely: You at GitHub also added it entirely :) => fff42755efc (pack-bitmap: add support for bitmap indexes, 2013-12-21). Anyway, I'm fine with removing it. From skimming that commit it was probably added for no particularly strong reason. But I found the omission of "it was added in xyz commit" to be sometihng that could be added to the commit message in this case, and.... > You could also imagine adding a configuration knob here to control > whether or not the warning is shown, but I find that to be kind of > gross. FWIW I don't find that to be particularly gross. I think it's fine to just delete it. But isn't this a general sign that we should perhaps have different output when "pack-objects" and the like is run "locally", v.s. when we're running via some server process, and end up spewing a message out that the user can't do anything about?
