Re: Idea: Avoid JOINs by using path expressions to follow FKs

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

In response to

Browse pgsql-hackers by date

  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