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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs
Date: 2021-03-31 16:54:00
Message-ID: CAFj8pRA3W7sO6LhXEf4-YiK+4JYjV=_Z2BCqHGRXqo4nD135ig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
>
> If using the -> notation, you would only need to manually
> inspect the tables involved in the remaining JOINs;
> since you could be confident all uses of -> cannot affect cardinality.
>
> I think this would be a win also for an expert SQL consultant working
> with a new complex data model never seen before.
>
>
I did not feel comfortable when I read about this proprietary extension of
SQL. I can accept and it can be nice to support ANSI/SQL object's
referentions, but implementing own syntax for JOIN looks too strange. I
don't see too strong benefit in inventing new syntax and increasing the
complexity and possible disorientation of users about correct syntax. Some
users didn't adopt a difference between old joins and modern joins, and you
are inventing a third syntax.

Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-03-31 17:01:38 Re: making update/delete of inheritance trees scale better
Previous Message Sebastian Cabot 2021-03-31 16:31:45 Re: Prevent query cancel packets from being replayed by an attacker (From TODO)