• parser : Only PostgreSQL-Parser
• parser-tests : parser + tests
• ast : Only PostgreSQL-AST
• ast-builder : parser + ast + PostgreSQL-ASTBuilder
• ast-tests : ast-builder + tests
• visitors : PostgreSQL-ASTVisitors
• core : ast-builder + visitors
• core-tests : core + ast-tests + parser-tests
• all : All packages except PostgreSQL-DevTools
• dev : all + PostgreSQL-DevTools

This issue requires issue #32 to be solved.

Because of a trick in the parser.

A solution to solve this is to do a pass after the parsing to modify the tree in order to fix that.

Another solution but harder is to fix the grammar...

See spec here: https://www.postgresql.org/docs/9.6/static/sql-expressions.html

https://www.postgresql.org/docs/9.6/static/plpgsql-control-structures.html

41.6.6.1. Obtaining Information About an Error

and

41.6.7. Obtaining Execution Location Information

Like that, it is possible to generate an specific object representing the wildcard when building the AST.

[ LATERAL ] ROWS FROM( function_name ( [ argument [, ...] ] ) [ AS ( column_definition [, ...] ) ] [, ...] )
                [ WITH ORDINALITY ] [ [ AS ] alias [ ( column_alias [, ...] ) ] ]

construct is not implemented. For now we can work without that anyway.

• libpgquery if for the whole SQL dump.
• PSQLParser if for PL/pgSQL.

Maybe generate a common AST from those so later process is easier.

Like truc[i]::machin

In PSQLGrammar. Sometimes it is used, sometimes #identifier is used.

#tableName is just an alias to #identifier, it should be removed.

Commands line SELECT, INSERT, DELETE, UPDATE, etc...

It looks like the following is valid PL/pgSQL:

EXECUTE format('SELECT count(*) FROM %I '
   'WHERE inserted_by = $1 AND inserted <= $2', tabname)
   INTO c
   USING checked_user, checked_date;

Trying to make the parser work without this part of the grammar completely written because it is unclear what has to be parsed.

It seems that SELECT INTO table * ... is a valid construct (apparently not documented in postgresql doc.

The parser should handle that.

This is done in PSQLGrammar>>#commaSubscriptWith:

I'm not sure this should be modified or not since the AST builder manage this "by hand".

Nevertheless I log this here in case time is found to fix this.

It can not be parsed for now because it takes an argument of the form x FROM y e.g. EXTRACT(DAY FROM origine)

Since there is huge number of unit tests, we may want to load the project without them.

An update of the baseline will be needed.

To ensure consistance in naming.

Like this one:

WITH upd AS (
  UPDATE employees SET sales_count = sales_count + 1 WHERE id =
    (SELECT sales_person FROM accounts WHERE name = 'Acme Corporation')
    RETURNING *
)
INSERT INTO employees_log SELECT *, current_timestamp FROM upd

Using tests of the crash tests classes.

A select query can use VALUES command as in the following example:

SELECT row1, row2, row3 FROM (VALUES (1, 'hello', 42))

Like var::machin::truc

See https://www.postgresql.org/docs/9.6/static/plpgsql-cursors.html

something like this foo(*)+42 is legal syntax.

To test the parser against a lot of queries and trying to ensure it works well.

Visitor methods in

• AST objects side
• Visitor side (empty or eventually with code template)

Apparently, in a SELECT query, it is possible to do the following in the selected columns:

SELECT aggregate(col) FILTER(condition) FROM table;

Needs to be investigated, this is an aggregate expression and should be managed by the parser but apparently it is not.

Details here: https://www.postgresql.org/docs/9.4/static/sql-expressions.html

This is valid syntax:

RETURN (1, 2, ''three''::text)

a Dictionary with the matching between identifiers would be returned.

This is generally incorrect, it should be only [...] separatedBy:[...].

This is valid expression:

FOR i IN 1..10 LOOP
    -- i will take on the values 1,2,3,4,5,6,7,8,9,10 within the loop
END LOOP;