On Tue, Apr 20, 2021 at 5:53 AM Tom Lane <tgl@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.