Re: Split-up ECPG patches - Mailing list pgsql-hackers

Boszormenyi Zoltan írta:
> OK, here's the WIP patch for the unified core/ecpg grammar,
> with opt_from_in. But I am still getting the 2 shift/reduce
> conflicts exactly for the FORWARD and BACKWARD rules
> that I was getting originally. Can you look at this patch and
> point me to the right direction in solving it? Thanks in advance.

Okay, I seem to start to succeed with the following strategy.
In ECPG, there's the possibility to ignore certain rules.
I just added these two lines to parse.pl:

$replace_line{'fetch_argsFORWARDopt_from_incursor_name'} = 'ignore';
$replace_line{'fetch_argsBACKWARDopt_from_incursor_name'} = 'ignore';

And I needed to pull up these into FetchStmt as:
    FETCH fetch_args FORWARD cursor_name
    FETCH fetch_args FORWARD from_in cursor_name
    FETCH fetch_args BACKWARD cursor_name
    FETCH fetch_args BACKWARD from_in cursor_name
    MOVE fetch_args FORWARD cursor_name
    MOVE fetch_args FORWARD from_in cursor_name
    MOVE fetch_args BACKWARD cursor_name
    MOVE fetch_args BACKWARD from_in cursor_name

But I have the following problem. When this is in ecpg.addon:
===============================
...
ECPG: FetchStmtFETCHfetch_args addon
ECPG: FetchStmtMOVEfetch_args addon
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;
...
ECPG: FetchStmtMOVEfetch_args rule
        | FETCH fetch_args ecpg_into
        {
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;
                $$ = cat2_str(make_str("fetch"), $2);
        }
...
===============================

After running parse.pl, I get this in preproc.y for FetchStmt:

===============================
  FetchStmt:
 FETCH fetch_args
 {
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;

 $$ = cat_str(2,make_str("fetch"),$2);
}
|  MOVE fetch_args
 {
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;
 { // THIS IS AN EXTRA "{"
 $$ = cat_str(2,make_str("move"),$2);
}
...
===============================

With this code, I can prevent the extra "{" emitted:

===============================
ECPG: FetchStmtMOVEfetch_args block
        {
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;
                $$ = cat2_str(make_str("move"), $2);
        }
        | FETCH fetch_args ecpg_into
        {
                add_additional_variables(current_cursor, false);
                free(current_cursor);
                current_cursor = NULL;
                $$ = cat2_str(make_str("fetch"), $2);
        }
...
===============================

And it bothers me, it looks illegal, but at least ugly.

With the first code, if I delete that extra "{" manually,
preproc.y compiles fine, and "make check" in ecpg fails
only one test, and the "failure" is only in the generated source
as now there's no "from" emitted in the ECPG-created
statements where FROM or IN doesn't appear in the
*.pgc code, but the stdout/stderr results are the same
as what's expected. Michael, can you give me some help here?
The attached patch uses the second variation, at least it
produces usable preproc.y that compiles into what I wanted.

In the attached patch I added a regression test, as well.
Actually, two, but they are the same, one copy under preproc,
one copy under compat_informix, so the difference in
ECPG runs an be observed.

You had a comment in a previous mail: "Some variable
handling commands look suspicious to me, a test case
might alleviate my concerns." I suspect you meant
introducing remove_variable_from_list(). The regression
tesst may help me prove the usefulness of this function,
especially in the FETCH :count FROM :curname; where
multiple $0 references occur, or the PREPARED statement
cases, where the order of the parameters passed to ECPGdo()
would come out reversed, or the dynamic cursor name would
get duplicated in some other statements.

I also tried to test this new code with a varchar cursor,
you're right, it didn't work with cursor name in a varchar
variable. I fixed this case now, reflected in the regression test.

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/