Re: bug with expression index on partition

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-22T20:54:52Z
Lists: pgsql-hackers
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.

I think the whole-row vars issue is worthy of some more thinking.  I'm
letting that one go for now.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. When index recurses to a partition, map columns numbers