Re: GSoC 2017: Foreign Key Arrays

*What I did:*

- read into the old patch but couldn't apply it since it's quite old. It
needs to be rebased and that's what I am working on. It's a lot of work.
- incomplete patch can be found attached here

*Bugs*

- problem with the @>(anyarray, anyelement) opertator: 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

*Suggestion:*

- since I needed to check if the Datum was null and its type, I had to
do it in the arraycontainselem and pass it as a parameter to the underlying
function array_contains_elem. I'm proposing to introduce a new struct like
ArrayType, but ElementType along all with brand new MACROs to make dealing
with anyelement easier in any polymorphic context.

Best Regards,
Mark Rofail

On Tue, Jun 20, 2017 at 12:19 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Mark Rofail wrote:
> > 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.
>
> OK, that's great.
>
> > *What I plan to do:*
> >
> > - I need to start working on the Referential Integrity code but I
> don't
> > where to start
>
> You need to study the old patch posted by Marco Nenciarini.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>