On Wed, Apr 22, 2020 at 2:45 PM amul sul <sula...@gmail.com> wrote: > > > On Wed, Apr 22, 2020 at 2:59 PM amul sul <sula...@gmail.com> wrote: > >> >> >> On Wed, Apr 22, 2020 at 2:27 PM David Rowley <dgrowle...@gmail.com> >> wrote: >> >>> On Wed, 22 Apr 2020 at 20:11, amul sul <sula...@gmail.com> wrote: >>> > >>> > On Wed, Apr 22, 2020 at 1:21 PM Rajkumar Raghuwanshi < >>> rajkumar.raghuwan...@enterprisedb.com> wrote: >>> >> #2 0x0000000000acd16a in ExceptionalCondition >>> (conditionName=0xc32310 "numfks == attmap->maplen", errorType=0xc2ea23 >>> "FailedAssertion", fileName=0xc2f0bf "tablecmds.c", lineNumber=9046) at >>> assert.c:67 >>> > >>> > >>> > Looks like this assertion is incorrect, I guess it should have check >>> > numfks <= attmap->maplen instead. >>> >>> Even that seems like a very strange thing to Assert. Basically it's >>> saying, make sure the number of columns in the foreign key constraint >>> is less than or equal to the number of attributes in parentRel. >>> >>> It's true we do disallow duplicate column names in the foreign key >>> constraint (at least since 9da867537), but why do we want an Assert to >>> say that? I don't see anything about that code that would break if we >>> did happen to allow duplicate columns in the foreign key. I'd say the >>> Assert should just be removed completely. >>> >> >> Understood and agree with you. >> >> Attached patch removes this assertion and does a slight tweak to >> regression test >> to generate case where numfks != attmap->maplen, IMO, we should have this >> even if there is nothing that checks it. Thoughts? >> > > Kindly ignore the previously attached patch, correct patch attached here. >
I did a quick test of the fix, the assertion failure is fixed and regression is not reporting any failures. > > Regards, > Amul > -- Highgo Software (Canada/China/Pakistan) URL : http://www.highgo.ca ADDR: 10318 WHALLEY BLVD, Surrey, BC EMAIL: mailto: ahsan.h...@highgo.ca
