[SQL/PGQ] Native executor for Graph query

Hello everyone,
After my previous email[1] I started to work on the custom node for VLE.
I managed to do it, but then I encountered a problem: it was
impossible to mix VLE and non-VLE patterns in a single query.
Therefore, I started working on a native planner / executor for graph
queries, you can find the result attached.

The feature is behind the GUC enable_native_graphtable (set to ON by
default), so switch to OFF to use the rewrite system.

There are some caveats:
- I did not start working on inheritance, partitioning, foreign
tables, and views, so queries on it may be inconsistent.
- Row level security is not something I even started to approach, so
expect lot of errors.
- Queries with lateral syntax are finicky at best, so tread carefully.

I have questions concerning the latter (and sorry if it was already
litigated in the original thread).
In the regression tests (for example graph_table.sql, line 161), we
have the query "SELECT * FROM x1, GRAPH_TABLE (...);".
According to the documentation, we are supposed to take the Cartesian
product of both tables.
x1 is defined with two rows, so we should get two rows (because there
is a single customer with adress = 'US'). What we
currently expect however, is the result of a simple JOIN on graph.cid and x1.a.
The question is then: How should the native executor handle those
cases ? I think rejecting the query outright is sensible,
as in those cases, x1 is not properly defined.
The same question applies to the other test with multiple sources in
SELECT, and in general to the LATERAL behaviour.

For the future (should this patch be accepted), then I (or other) can
work on supporting other path_mode (currently only
WALK is used), other graph traversal algorithms (BFS, Bidirectional,
or for some insane reason A*), and add ways to make
use of the optimizer (push down WHERE / IS conditions, use indexes,
split hop patterns and group afterwards, etc.).

I also attached the graph links I used to write the expected output
for the VLE tests.

Best regards,
Henri GASC

[1]: https://www.postgresql.org/message-id/flat/CAJyuuthCZ8yQuUAy_1d0DkxtdQ_aZcOX%2B7bcwagwvAF6BSrHeg%40mail.gmail.com

Classification: Privacy: Basic Personal Data; Export Control: Not
Technical; National Security: Not National Security; Company
Classification: Not Applicable; Business or Private Data: Business
data
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.