Re: Bogus collation version recording in recordMultipleDependencies - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Bogus collation version recording in recordMultipleDependencies
Date
Msg-id CAH2-WzkQQazrDZOqUSfBi19SZtUqm=ih2ungG0SZD_biBpK0jQ@mail.gmail.com
Whole thread Raw
In response to Re: Bogus collation version recording in recordMultipleDependencies  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bogus collation version recording in recordMultipleDependencies
List pgsql-hackers
On Mon, Apr 19, 2021 at 10: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.  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.

Is it really the case that static analysis of the kind that you'd need
to make this 100% robust is fundamentally impossible? I find that
proposition hard to believe.

I'm not sure that you were making a totally general statement, rather
than a statement about the patch/implementation, so perhaps I just
missed the point.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: when the startup process doesn't
Next
From: Peter Geoghegan
Date:
Subject: Re: Bogus collation version recording in recordMultipleDependencies