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.
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
