This library uses the actual PostgreSQL server source to parse SQL queries and return the internal PostgreSQL parse tree.Note that this is mostly intended as a base library for
- pg_query (Ruby),
- pg_query.go (Go),
- pg-query-parser (Node),
- psqlparse (Python) and
- pglast (Python 3)."
"
Best,
Imre
Hello,
1. I was told that M$ SQLServer provides huge performance deltas over PostgreSQL when dealing with index-unaligned queries :
create index i on t (a,b, c);
select * from t where b=... and c=...;
Columnar storage has been tried by various companies, CitusData, EnterpriseDB, 2ndQuadrant, Fujitsu Enterprise Postgres. It has been discussed quite a lot, last thread that I was able to find being in 2017, https://www.postgresql.org/message-id/CAJrrPGfaC7WC9NK6PTTy6YN-NN%2BhCy8xOLAh2doYhVg5d6HsAA%40mail.gmail.com where Fujitsu's patch made it quite far.
What is the status on such a storage manager extension interface ?
2. What do you think of adding a new syntax : 'from t join t2 using (fk_constraint)' ? And further graph algorithms to make automatic joins ?
Both 'natural join' and 'using (column_name)' are useless when the columns are not the same in source and destination.
Plus it is often the case that the fk_constraints are over numerous columns, even though this is usually advised against. But when this case happens there will be a significant writing speedup.
I have been bothered by this to the point that I developed a graphical-query-builder plugin for pgModeler,
https://github.com/maxzor/plugins/tree/master/graphicalquerybuilder#automatic-join-mode ,
but I believe such a syntax would be much better in the core!3. What is the status of making the internal parser of PostgreSQL less coupled to the core, and easier to cherry-pick from outside?
It would be great to incorporate it into companion projects : pgAdmin4, pgModeler, pgFormatter...BR, Maxime Chambonnet