From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, "postgresql(at)zr40(dot)nl" <postgresql(at)zr40(dot)nl>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable |
Date: | 2021-10-18 07:46:40 |
Message-ID: | YW0mYDzpVhEjcbNp@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, Oct 14, 2021 at 11:07:21AM +0900, Michael Paquier wrote:
> This means that we've lost the ability to enforce n_distinct for
> expression indexes for two years. But, do we really care about this
> case? My answer to that would be "no" as long as we don't have a
> documented grammar rather, and we don't dump them either. But I think
> that we'd better do something with the code in analyze.c rather than
> letting it just dead, and my take is that we should remove the call to
> get_attribute_options() for this code path.
>
> Any opinions? @Robert: you were involved in 76a47c0, so I am adding
> you in CC.
Hearing nothing, and after pondering on this point, I think that
removing the get_attribute_options() is the right way to go for now
if there is a point in the future to get n_distinct done for all index
AMs.
I have reviewed the last patch posted upthread, and while testing
partitioned indexes I have noticed that we don't need to do a custom
check as part of ATExecSetOptions(), because we have already that in
ATSimplePermissions() with details on the relkind failing. This makes
the patch simpler, with a better error message generated. I have
added a case for partitioned indexes while on it.
Worth noting that I have spotted an extra weird call of
get_attribute_options() in extended statistics. This is unrelated to
this thread and I am not done analyzing it yet, but a quick check
shows that we call it with an InvalidOid for expression stats, which
is surprising.. I'll start a thread once/if I find anything
interesting on this one.
Attached is the patch I am finishing with, that should go down to
v13 (this is going to conflict on REL_13_STABLE, for sure).
Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
disallow_alter_index_column_set_v2.patch | text/x-diff | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-10-18 09:59:56 | Re: Snapshot leak warning with lo_export in subtransaction |
Previous Message | David G. Johnston | 2021-10-18 04:51:47 | Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause |
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2021-10-18 08:03:26 | Re: [Bug] Logical Replication failing if the DateStyle is different in Publisher & Subscriber |
Previous Message | Xing GUO | 2021-10-18 07:38:13 | Re: try_relation_open and relation_open behave different. |