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

From Julien Rouhaud
Subject Re: Idea: Avoid JOINs by using path expressions to follow FKs
Date
Msg-id 20210330072844.gifuie2j6k7cyqyr@nol
Whole thread Raw
In response to Re: Idea: Avoid JOINs by using path expressions to follow FKs  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Idea: Avoid JOINs by using path expressions to follow FKs
List pgsql-hackers
On Tue, Mar 30, 2021 at 09:02:39AM +0200, Pavel Stehule wrote:
> út 30. 3. 2021 v 8:52 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
> 
> > On Tue, Mar 30, 2021 at 08:03:09AM +0200, Pavel Stehule wrote:
> > >
> > > On second hand, it can be very nice to have some special strict mode in
> > > Postgres - maybe slower, not compatible, that disallow some dangerous or
> > > unsafe queries. But it is possible to solve in extensions, but nobody did
> > > it. Something like plpgsql_check for SQL - who will write sql_check?
> >
> > The #1 cause of problems is probably unqualified outer references, and
> > unfortunately I don't think it's really possible to detect that in an
> > extension, as the required information is only available in the raw
> > parsetree.
> >
> 
> the raw parsetree is available  I think. I didn't check it. But it can be
> easy to attach or attach a copy to Query structure. Maybe there is no
> necessary hook. But it can be a good reason for implementing a post parsing
> hook.

It's not available in any existing hook.  And even if it was you would have to
import most of transformTopLevelStmt() and all underlying functions to be able
to detect this case I think.  This should be best done in core postgres.

> It should be easy to check if all joins are related to foreign key
> constraints.

Yes, and also if the referenced columns are covered by indexes for instance.
My concern is mostly that you won't be able to cover the unqualified outer
references, which can lead to wrong query results rather than just slow
queries.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Flaky vacuum truncate test in reloptions.sql
Next
From: Pavel Stehule
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs