ECPG patch views [moved from RRR list]

Started by Dan Colishover 16 years ago1 messages

dan@unencrypted.org

over 16 years ago

----- Forwarded message from Robert Haas <robertmhaas@gmail.com> -----

Date: Sun, 27 Sep 2009 12:52:35 -0400
From: Robert Haas <robertmhaas@gmail.com>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Dan Colish <dan@unencrypted.org>, pgsql-rrreviewers@postgresql.org,
Jeff Janes <jeff.janes@gmail.com>,
Hans-Juergen Schoenig <hs@cybertec.at>,
Michael Meskes <meskes@postgresql.org>
Subject: Re: CF 2009-09: initial reviewing assignments

2009/9/27 Boszormenyi Zoltan <zb@cybertec.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

----- End forwarded message -----

I'm bumping this message to pg-hackers.

Here is a link to the archive as well:
http://archives.postgresql.org/pgsql-rrreviewers/2009-09/msg00039.php

--
--Dan