Re: bug with expression index on partition
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-25T02:57:41Z
Lists: pgsql-hackers
On 2018/06/23 5:54, Alvaro Herrera wrote: > On 2018-Jun-21, Amit Langote wrote: > >> On 2018/06/21 15:35, Amit Langote wrote: >>> So, CompareIndexInfo and generateClonedIndexStmt are both doing the right >>> thing, but DefineIndex is not. Attached is a patch to fix DefineIndex so >>> that it converts indexParams before recursing to create the index on a >>> partition. >> >> I noticed that while CompareIndexInfo and generateClonedIndexStmt would >> reject the case where index expressions contain a whole-row Var, my patch >> didn't teach to do the same to DefineIndex, causing asymmetric behavior. >> So, whereas ATTACH PARTITION would error out when trying to clone a >> parent's index that contains a whole-row Var, recursively creating an >> index on partition won't. >> >> I updated the patch so that even DefineIndex will check if any whole-row >> Vars were encountered during conversion and error out if so. > > Thanks. I pushed this version, although I tweaked the test so that this > condition is verified in the test that is supposed to do so, rather than > creating a whole new set of tables for this purpose. The way it would > fail with unpatched code is perhaps less noisy that what you proposed, > but I think it's quite enough. Thanks. The test changes you committed seem fine. Regards, Amit
Commits
-
When index recurses to a partition, map columns numbers
- 475be5e790e2 11.0 landed