Re: [HACKERS] GSoC 2017: Foreign Key Arrays

From: Mark Rofail <markm(dot)rofail(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andreas Karlsson <andreas(at)proxel(dot)se>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, Erik Rijkers <er(at)xs4all(dot)nl>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Date: 2021-02-15 19:34:54
Message-ID: CAJvoCuvTSiKYD5Kt+3n6Fjd0M+4Y9uK6JYrA8F5n_9oh=ixz2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear All,

I know that avoiding trivial coercion problems is convenient but at the end
of the day, it's the DB Architect's job to use the proper tables to be able
to use FK Arrays.
For instance, if we have two tables, TABLE A (atest1 int2) and TABLE B
(btest1 int, btest2 int4[]) and an FK constraint between A(atest1) and
B(btest2), it simply shouldn't work. btest2 should be of type int2[].
Thus, I have reverted back the signature @>>(anyarray,anyelement) and
<<@(anyelement,anyarray). I am open to discuss this if anyone has any
input, would be appreciated.

Please find the "anyarray_anyelement_operators-v3.patch" attached below.

Changelog:
- v3 (compatible with current master 2021-02-15,
commit 0e5290312851557ee24e3d6103baf14d6066695c)
* refactor ginqueryarrayextract in ginarrayproc.c
* revert back the signature @>>(anyarray,anyelement) and
<<@(anyelement,anyarray)

On Mon, Feb 15, 2021 at 5:35 PM Joel Jacobson <joel(at)compiler(dot)org> wrote:

> Hi all,
>
> I've reviewed Mark's anyarray_anyelement_operators-v2.patch
> and the only remaining issue I've identified is the opr_sanity problem.
>
> Mark seems to be in need of some input here from more experienced hackers,
> see below.
>
> Hopefully someone can guide him in the right direction.
>
> /Joel
>
> On Sat, Feb 13, 2021, at 11:49, Mark Rofail wrote:
> >Hey Joel,
> >
> >test opr_sanity ... FAILED
> >
> > AND binary_coercible(p2.opcintype, p1.amoplefttype));
> > amopfamily | amopstrategy | amopopr
> >------------+--------------+---------
> >-(0 rows)
> >+ 2745 | 5 | 6105
> >+(1 row)
> >-- Operators that are primary members of opclasses must be immutable (else
> >-- it suggests that the index ordering isn't fixed). Operators that are
> >This is due using anycompatiblearray for the left operand in @>>.
> >To solve this problem we need to use @>>(anyarray,anyelement) or
> introduce a new opclass for gin indices.
> >These are the two approaches that come to mind to solve this. Which one
> is the right way or is there another solution I am not aware of?
> >That’s why I’m asking this on the mailing list, to get the community’s
> input.
>
>
>

Attachment Content-Type Size
anyarray_anyelement_operators-v3.patch text/x-patch 26.6 KB
fk_arrays_elem_v1.patch text/x-patch 125.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2021-02-15 19:41:39 Re: PG vs LLVM 12 on seawasp, next round
Previous Message Justin Pryzby 2021-02-15 19:33:41 Re: CREATE INDEX CONCURRENTLY on partitioned index