Fabien COELHO <coe...@cri.ensmp.fr> writes: >> I'm pretty clearly in favor of doing correct lexing. I think we should >> generalize that and make it reusable. psql has it's own hacked up >> version already, there seems little point in having variedly good copies >> around.
> I must admit that I do not know how to share lexer rules but have > different actions on them (psql vs sql parser vs ...), as the action code > is intrinsically intertwined with expressions. Obviously this is scope creep of the first magnitude, but ISTM that it would be possible to share a lexer between psql and pgbench, since in both of them the basic requirement is "break SQL commands apart and identify newline-terminated backslash commands". If we're gonna break pgbench's backwards compatibility anyway, there would be a whole lot to be said for just going over to psql's input parsing rules, lock stock 'n barrel; and this would be a good way to achieve that. As it stands, psqlscan.l has some external dependencies on the rest of psql, but we could perhaps refactor some of those away, and provide dummy implementations to satisfy others (eg pgbench could provide a dummy GetVariable() that just always returns NULL). So I'm imagining symlinking psqlscan.l into src/bin/pgbench and using it as-is (possibly after refactoring in psql). A possible issue is avoiding unnecessary invocations of flex, though. Maybe symlinking the .c file would work better. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers