Re: Idea: Avoid JOINs by using path expressions to follow FKs - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: Idea: Avoid JOINs by using path expressions to follow FKs
Date
Msg-id 31516d8b-3c11-72ff-fc83-e549aba1f5ac@postgresfriends.org
Whole thread Raw
In response to Re: Idea: Avoid JOINs by using path expressions to follow FKs  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: Idea: Avoid JOINs by using path expressions to follow FKs  ("Joel Jacobson" <joel@compiler.org>)
List 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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: Tomas Vondra
Date:
Subject: Re: Merging statistics from children instead of re-sampling everything