PostgreSQL array of elements that each are a foreign key

Question

I am attempting to create a DB for my app and one thing I'd like to find the best way of doing is creating a one-to-many relationship between my Users and Items tables.

I know I can make a third table, ReviewedItems, and have the columns be a User id and an Item id, but I'd like to know if it's possible to make a column in Users, let's say reviewedItems, which is an integer array containing foreign keys to Items that the User has reviewed.

If PostgreSQL can do this, please let me know! If not, I'll just go down my third table route.

Solution 1

No, this is not possible.

PostgreSQL is a relational DBMS, operating most efficiently on properly normalized data models. Arrays are - by definition, they are ordered sets - not relational data structures and the SQL standard therefore does not support defining foreign keys on array elements, and neither does PostgreSQL.

You can, however, build a perfectly fine database with array elements linking to primary keys in other tables. Those array elements, however, can not be declared to be foreign keys and the DBMS will therefore not maintain referential integrity.

Solution 2

It may soon be possible to do this: https://commitfest.postgresql.org/17/1252/ - Mark Rofail has been doing some excellent work on this patch!

The patch will (once complete) allow

CREATE TABLE PKTABLEFORARRAY (
    ptest1 float8 PRIMARY KEY,
    ptest2 text
);
CREATE TABLE FKTABLEFORARRAY (
    ftest1 int[],
    FOREIGN KEY (EACH ELEMENT OF ftest1) REFERENCES PKTABLEFORARRAY,
    ftest2 int
);

However, author currently needs help to rebase the patch (beyond my own ability) so anyone reading this who knows Postgres internals please help if you can.

Comments

[a_horse_with_no_name]

You can define a constraint trigger that would check that. But I'm not sure if it works reliably in all cases.

[Luan Huynh]

@a_horse_with_no_name: could you give an example about reliably in all cases ? You mean sometimes trigger can be failed ? Thanks.

[a_horse_with_no_name]

@LuanHuynh: I don't recall the (technical) details, but the last time this was discussed on the mailing list someone mentioned that a corresponding constraint trigger might not catch all cases - but that might no longer be true

[Zach]

Thanks, I guess I'll just make a relationship table for them

[Victor]

very HOT indeed... CREATE TABLE FKTABLEFORARRAY ( ftest1 int[], FOREIGN KEY (EACH ELEMENT OF ftest1) REFERENCES PKTABLEFORARRAY, ftest2 int )

[yoonghm]

The patch is awaiting author to follow up. Until the feature is available, you will have to use trigger to check integrity which may be slow.

[OrangeDog]

@a_horse_with_no_name can you post an answer with an example of such a constraint?

[Teocali]

shame, it doesn't seems to have been included :(

[Muhammad Asim]

does it increase performance somehow ? Or should someone stick to the third table approach ?

[M Imam Pratama]

2020, still unsupported: postgresql.org/docs/13/unsupported-features-sql-standard.htm‌​l

[karianpour]

This is really useful.

[Jean Monet]

workaround / re-design: having a separate many-to-many table

[Phil Frost]

Apparently, sql:2016 does support this behavior. Unfortunately the standard isn't freely available, but you can see it referenced in both Microsoft's documentation and PostgreSQL's list of unsupported standard features.

[user45392]

Per the patch email thread, as of July 2021 it appears that this "still requires some major surgery." So we could still have a while.

[m4heshd]

Holy moly it's 2022 and still unsupported.

[Lalit Fauzdar]

If it's still unsupported, why these upvotes? Am I missing something?

[John O]

@LalitFauzdar Mostly because it's awesome. You might be missing how awesome this would be.

[Moshe Katz]

@JohnO It would definitely be awesome, but upvotes are really supposed to be for useful answers and this answer isn't currently useful because the behavior it describes is still not implemented. As of right now, there is only one truly correct answer to the question: "you can't do it". (I upvoted this one too, but that probably wasn't really the right thing to do.)