From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
Cc: | "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Idea: Avoid JOINs by using path expressions to follow FKs |
Date: | 2021-03-28 14:39:39 |
Message-ID: | 2cd5681d-3b5d-420d-8b6e-b88802038921@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 28, 2021, at 16:04, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net <mailto:andrew%40dunslane.net>> writes:
> > Maybe. I don't recall ever having seen a column with more than one FK.
> > Is that a common thing? In itself it seems like a bad idea.
>
> Yeah, that aspect seems like a complete show-stopper. We have a way
> to enforce that you can't *drop* a constraint that some stored view
> depends on for semantic validity. We don't have a way to say that
> you can't *add* a constraint-with-certain-properties. And I don't
> think it'd be very practical to do (consider race conditions, if
> nothing more).
Thanks for valuable insights, I didn't think about these things.
What if the path expressions are just syntactic sugar for an INNER JOIN on the referencing -> referenced column?
If a VIEW is created using this syntax, it would be stored as INNER JOINs, similar to how SELECT * is expanded.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-03-28 14:40:21 | Re: Idea: Avoid JOINs by using path expressions to follow FKs |
Previous Message | Tom Lane | 2021-03-28 14:04:53 | Re: Idea: Avoid JOINs by using path expressions to follow FKs |