Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Поиск
Список
Период
Сортировка
От Mark Rofail
Тема Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Дата
Msg-id CAJvoCusCfrW3r2HF3rGi_hAbkbxZg_ApPK=NsOj1eeBqFck9Sg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Список pgsql-hackers
According to the last review, there are still two main issues with the patch.

On Mon, Oct 30, 2017 at 3:24 AM, Andreas Karlsson <andreas@proxel.se> wrote:
1) MATCH FULL does not seem to care about NULLS in arrays. In the example below I expected both inserts into the referring table to fail.

CREATE TABLE t (x int, y int, PRIMARY KEY (x, y));
CREATE TABLE fk (x int, ys int[], FOREIGN KEY (x, EACH ELEMENT OF ys) REFERENCES t MATCH FULL);
INSERT INTO t VALUES (10, 1);
INSERT INTO fk VALUES (10, '{1,NULL}');
INSERT INTO fk VALUES (NULL, '{1}');

CREATE TABLE
CREATE TABLE
INSERT 0 1
INSERT 0 1
ERROR:  insert or update on table "fk" violates foreign key constraint "fk_x_fkey"
DETAIL:  MATCH FULL does not allow mixing of null and nonnull key values.

I understand that Match full should contain nulls in the results. However, I don't think that it's semantically correct, so I suggest we don't use Match full. What would be the consequences of that ?

2) I think the code in RI_Initial_Check() would be cleaner if you used "CROSS JOIN LATERAL unnest(col)" rather than having unnest() in the target list. This way you would not need to rename all columns and the code paths for the array case could look more like the code path for the normal case.
I have repeatedly tried to generate the suggested query using C code and I failed. I would like some help with it

Best Regards,
Mark Rofail

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: CREATE ROUTINE MAPPING
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)