Re: CF 2009-09: initial reviewing assignments

2009/9/27 Boszormenyi Zoltan <zb(at)cybertec(dot)at>:
>>
>> On Sat, Sep 26, 2009 at 11:39:45AM -0700, Jeff Janes wrote:
>> > Hi Robert,
>> >
>> > Is there another patch you'd like me to work on?
>> >
>> > Lock wait statistics says it needs review, but the last comment
>> > suggests it is waiting on author.
>> >
>> > Enhancements to COPY (error logging and autopartitioning) says it is
>> > waiting on author but last comment suggests perhaps it is ready for
>> > review.
>> >
>> > I've taken a look at ECPG, but I couldn't make heads or tails of it.
>> > I guess I could try harder :)
>> >
>> > It looks like the ECPG patches are not independent and need to applied
>> > in a particular order in order for them to apply cleanly to HEAD.
>> >
>> > So I think I need some guidance on what I should be doing.
>> >
>> > Thanks,
>> >
>> > Jeff
>> >
>>
>> I've been looking at the dynamic cursor names patch, so if you have any
>> insights I would really appreciate them. I am having some trouble fully
>> reviewing this patch because I am not very familiar with the ecpg code.
>>
>> --
>> --Dan
>>
>
> Asketh and you shall be given. :-)
>
> May I help you in understanding ECPG?
>
> The dynamic cursorname patch was started on 8.3.7 first
> and we moved to 8.4 (then 8.5) CVS because in 8.4,
> ECPG grammar was rewritten to be auto-generated
> from the core grammar. I had to dive in kneep deep
> before I could modify it...
>
> Basic thing is that ECPG modifies and extends the core
> grammar in a way that
> 1) every token in ECPG is <str> type. New tokens are
>   defined in ecpg.tokens, types are defined in ecpg.type
> 2) most tokens from the core grammar are simply converted
>   to literals concatenated together to form the SQL string
>   passed to the server, this is done by parse.pl.
> 3) some rules need side-effects, actions are either added
>   or completely overridden (compared to the basic token
>   concatenation) for them, these are defined in ecpg.addons,
>   the rules for ecpg.addons are explained below.
> 4) new grammar rules are needed for ECPG metacommands.
>   These are in ecpg.trailer.
> 5) ecpg.header contains common functions, etc. used by
>   actions for grammar rules.
>
> In "ecpg.addons", every modified rule follows this pattern:
>       ECPG: dumpedtokens postfix
> where "dumpedtokens" is simply tokens from core gram.y's
> rules concatenated together. e.g. if gram.y has this:
>       ruleA: tokenA tokenB tokenC {...}
> then "dumpedtokens" is "ruleAtokenAtokenBtokenC".
> "postfix" above can be:
> a) "block" - the automatic rule created by parse.pl is completely
>    overridden, the code block has to be written completely as
>    it were in a plain bison grammar
> b) "rule" - the automatic rule is extended on, so new syntaxes
>    are accepted for "ruleA". E.g.:
>      ECPG: ruleAtokenAtokenBtokenC rule
>          | tokenD tokenE { action_code; }
>          ...
>    It will be substituted with:
>      ruleA: <original syntax forms and actions up to and including
>                    "tokenA tokenB tokenC">
>             | tokenD tokenE { action_code; }
>             ...
> c) "addon" - the automatic action for the rule (SQL syntax constructed
>    from the tokens concatenated together) is prepended with a new
>    action code part. This code part is written as is's already inside
>    the { ... }
>
> Multiple "addon" or "block" lines may appear together with the
> new code block if the code block is common for those rules, which
> is a very smart thing.
>
> This was what I gathered from the code. The documentation
> seems to be missing from the rewritten ECPG grammar in 8.4.
> Michael, am I missing something?
>
> Dan, please, start the review in light of the above.
> If you have any questions, don't hesitate to ask.

Please move this discussion to -hackers, maybe with a link back to
this post. Good info, wrong place. :-)

...Robert