On Fri, Jul 5, 2024 at 10:59 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> The cfbot noticed that this patchset had a conflict with d35cd0619,
> so here's a rebase. It's just a rebase of v1, no other changes.
Hi Tom,
I started looking at the earlier cleanup patches.
0001 seems straightforward. Note: It doesn't apply cleanly anymore,
but does with 'patch'.
0002 LGTM, just a couple minor comments:
--- a/src/interfaces/ecpg/preproc/parse.pl
+++ b/src/interfaces/ecpg/preproc/parse.pl
@@ -1,7 +1,13 @@
#!/usr/bin/perl
# src/interfaces/ecpg/preproc/parse.pl
# parser generator for ecpg version 2
-# call with backend parser as stdin
+#
+# See README.parser for some explanation of what this does.
Doesn't this patch set put us up to version 3? ;-) Looking in the
history, a very long time ago a separate "parse2.pl" was committed for
some reason, but that was reconciled some time later. This patch
doesn't need to get rid of that meaningless version number, but I find
it distracting.
+ # There may be multiple ECPG: lines and then multiple lines of code.
+ # Each block of code needs to be added to all prior ECPG records.
This took me a while to parse at first. Some places in this script put
quotes around words-with-colons, and that seems good for readability.
0003:
Looks a heck of a lot better, but I didn't try to understand
everything in the script, either before or after.
+ # Emit the target part of the rule.
+ # Note: the leading space is just to match
+ # the old, rather weird output logic.
+ $tstr = ' ' . $non_term_id . ':';
+ add_to_buffer('rules', $tstr);
Removing the leading space (or making it two spaces) has no effect on
the output -- does that get normalized elsewhere?
That's all I have for now.
