On Tue, Apr 20, 2021 at 5:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I think that the real fundamental bug is supposing that static analysis > can give 100% correct answers. ...
Well, the goal was to perform analysis to the extent possible statically since that would cover the vast majority of cases and is practically all you can do. Clearly there is always going to be a category of invisible dependencies inside procedural code in general (halting problem). We did think about the idea of using new declarations about functions/operators to know which ones actually care about collation, rather than assuming that they all do (bugs aside), as an optimisation, and then that mechanism could in theory also be used to say that functions that don't appear to depend on collations actually do internal, but that all seemed like vast overkill, so we left it for possible later improvements. The question on my mind is whether reverting the feature and trying again for 15 could produce anything fundamentally better at a design level, or would just fix problems in the analyser code that we could fix right now. For example, if you think there actually is a potential better plan than using pg_depend for this, that'd definitely be good to know about. > ... Even if it did do so in a given state > of the database, consider this counterexample: > > create type myrow as (f1 int, f2 int); > create table mytable (id bigint, r1 myrow, r2 myrow); > create index myindex on mytable(id) where r1 < r2; > alter type myrow add attribute f3 text; > > myindex is recorded as having no collation dependency, but that is > now wrong. Hrmph. Yeah. We didn't consider types that change later like this, and handling those correctly does seem to warrant some more thought and work than we perhaps have time for. My first thought is that we'd need to teach it to trigger reanalysis.