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

From Joel Jacobson
Subject Re: Idea: Avoid JOINs by using path expressions to follow FKs
Date
Msg-id 3b2ba267-7b51-4e55-9ea0-38f70eaa58cf@www.fastmail.com
Whole thread Raw
In response to Re: Idea: Avoid JOINs by using path expressions to follow FKs  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: Idea: Avoid JOINs by using path expressions to follow FKs  (Isaac Morland <isaac.morland@gmail.com>)
List pgsql-hackers
On Tue, Mar 30, 2021, at 21:02, Isaac Morland wrote:
On Tue, 30 Mar 2021 at 14:30, Joel Jacobson <joel@compiler.org> wrote:


If the expression ends with a column_name,
you get the value for the column.

If the expression ends with a constraint_name,
you get the referenced table as a record.

Can’t you just leave off the “ends with a column_name” part? If you want one of its columns, just put .column_name:

table -> constraint -> ... -> constraint . column_name

Then you know that -> expects a constraint_name and only that to its right.

+1

Of course! Much simpler. Thanks.


Also, should the join be a left join, which would therefore return a NULL when there is no matching record? Or could we have a variation such as ->? to give a left join (NULL when no matching record) with -> using an inner join (record is not included in result when no matching record).

Interesting idea, but I think we can keep it simple, and still support the case you mention:

If we only have -> and you want to exclude records where the column is NULL (i.e. INNER JOIN),
I think we should just use the WHERE clause and filter on such condition.


For the record I would find something like this quite useful. I constantly find myself joining in code lookup tables and the like, and while from a mathematical view it’s just another join, explicitly listing the table in the FROM clause of a large query does not assist with readability to say the least.

Thanks for the encouraging words. I have exactly the same experience myself and share your view.

I look forward to continued discussion on this matter.

/Joel

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: pgbench - add pseudo-random permutation function
Next
From: Fujii Masao
Date:
Subject: Re: Get memory contexts of an arbitrary backend process