| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Joel Jacobson <joel(at)compiler(dot)org> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, 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 21:18:14 |
| Message-ID: | e1e3b3d1-d337-db15-71c9-d1e4da6f5e9c@postgresfriends.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/31/21 6:54 PM, Pavel Stehule wrote:
>>
>>
>>
>> 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.
I'm with you on this: let's do it the Standard way, or not do it at all.
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-03-31 21:19:31 | Re: What to call an executor node which lazily caches tuples in a hash table? |
| Previous Message | Joel Jacobson | 2021-03-31 21:16:29 | Re: Idea: Avoid JOINs by using path expressions to follow FKs |