Re: [PATCH] Keeps tracking the uniqueness with UniqueKey - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Date
Msg-id CAApHDvrhOMPZKSugH6jnTCNFC2Nb+KGcXegJoas2FBvvSkDe-A@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Keeps tracking the uniqueness with UniqueKey  (Andy Fan <zhihui.fan1213@gmail.com>)
List pgsql-hackers
On Fri, 3 Apr 2020 at 16:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (It occurs to me BTW that we've been overly conservative about using
> NOT NULL constraints in planning, because of failing to consider that.
> Addition or drop of NOT NULL has to cause a change in
> pg_attribute.attnotnull, which will definitely cause a relcache inval
> on its table, cf rules in CacheInvalidateHeapTuple().  So we *don't*
> need to have a pg_constraint entry corresponding to the NOT NULL, as
> we've mistakenly supposed in some past discussions.)

Agreed for remove_useless_groupby_columns(), but we'd need it if we
wanted to detect functional dependencies in
check_functional_grouping() using unique indexes.



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: WAL usage calculation patch
Next
From: Amit Kapila
Date:
Subject: Re: WAL usage calculation patch