Re: [HACKERS] GSoC 2017: Foreign Key Arrays - Mailing list pgsql-hackers

From Mark Rofail
Subject Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date
Msg-id CAJvoCutPeRsPm2whZ7OxuvZr7UkTJk0530ygFe5GaJwgewEkOg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Okay, so major breakthrough.

Updates:
  • The operator @>(anyarray, anyelement) is now functional
    • The segmentation fault was due to applying PG_FREE_IF_COPY on a datum when it should only be applied on TOASTed inputs
    • The only problem now is if for example you apply the operator as follows  '{AAAAAAAAAA646'}' @> 'AAAAAAAAAA646' it maps to @>(anyarray, anyarray) since 'AAAAAAAAAA646' is interpreted as char[] instead of Text
  • Added some regression tests (src/test/regress/sql/arrays.sql) and their results(src/test/regress/expected/arrays.out)
  • wokred on the new GIN strategy, I don't think it would vary much from GinContainsStrategy.
What I plan to do:
  • I need to start working on the Referential Integrity code but I don't where to start
Best Regards,
Mark Rofail


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files
Next
From: "David G. Johnston"
Date:
Subject: Re: [HACKERS] psql's \d and \dt are sending their complaints todifferent output files