Re: CF 2009-09: initial reviewing assignments

>
> 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.

Best regards,
Zoltán Böszörményi

--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/