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

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Joel Jacobson <joel(at)compiler(dot)org>, 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-29 18:53:55
Message-ID: 31516d8b-3c11-72ff-fc83-e549aba1f5ac@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/29/21 7:55 PM, Joel Jacobson wrote:
> On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote:
>> CREATE TABLE order_details (
>> "order" REF(orders),
>> product REF(products),
>> quantity integer,
>> PRIMARY KEY ("order", product)
>> );
>>
>>
>> And the query would be:
>>
>> SELECT DISTINCT order_details."order"->customer->company_name
>> FROM order_details
>> WHERE order_details.product->product_name = 'Chocolade';
>>
>>
>> Postgres already supports most of that, but not all of it.
>
> Do you know if REF is meant to be a replacement for foreign keys?
>
> Are they a different thing meant to co-exist with foreign keys,
> or are they actually foreign keys "under the hood"
> or something else entirely?

They're supposed to be OOP where each row in the typed table is an
instance of the object. Types can also have methods associated with
them, and the instance tables can have subtables similar to our table
inheritance. The dereference operator is replaced by a subquery.

There is a whole slew of things in this area of the standard that
apparently never caught on.
--
Vik Fearing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-03-29 19:24:19 Re: Merging statistics from children instead of re-sampling everything
Previous Message Fujii Masao 2021-03-29 18:45:04 Re: TRUNCATE on foreign table