1ECPG modifies and extends the core grammar in a way that 21) every token in ECPG is <str> type. New tokens are 3 defined in ecpg.tokens, types are defined in ecpg.type 42) most tokens from the core grammar are simply converted 5 to literals concatenated together to form the SQL string 6 passed to the server, this is done by parse.pl. 73) some rules need side-effects, actions are either added 8 or completely overridden (compared to the basic token 9 concatenation) for them, these are defined in ecpg.addons, 10 the rules for ecpg.addons are explained below. 114) new grammar rules are needed for ECPG metacommands. 12 These are in ecpg.trailer. 135) ecpg.header contains common functions, etc. used by 14 actions for grammar rules. 15 16In "ecpg.addons", every modified rule follows this pattern: 17 ECPG: dumpedtokens postfix 18where "dumpedtokens" is simply tokens from core gram.y's 19rules concatenated together. e.g. if gram.y has this: 20 ruleA: tokenA tokenB tokenC {...} 21then "dumpedtokens" is "ruleAtokenAtokenBtokenC". 22"postfix" above can be: 23a) "block" - the automatic rule created by parse.pl is completely 24 overridden, the code block has to be written completely as 25 it were in a plain bison grammar 26b) "rule" - the automatic rule is extended on, so new syntaxes 27 are accepted for "ruleA". E.g.: 28 ECPG: ruleAtokenAtokenBtokenC rule 29 | tokenD tokenE { action_code; } 30 ... 31 It will be substituted with: 32 ruleA: <original syntax forms and actions up to and including 33 "tokenA tokenB tokenC"> 34 | tokenD tokenE { action_code; } 35 ... 36c) "addon" - the automatic action for the rule (SQL syntax constructed 37 from the tokens concatenated together) is prepended with a new 38 action code part. This code part is written as is's already inside 39 the { ... } 40 41Multiple "addon" or "block" lines may appear together with the 42new code block if the code block is common for those rules. 43