From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: ECPG cleanup and fix for clang compile-time problem |
Date: | 2024-08-12 10:46:22 |
Message-ID: | CANWCAZbDpWto=txWDc7p8cpsdSr0-T+9-juKHkWeYBSEuVe=4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 5, 2024 at 10:59 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2024-08-12 10:47:08 | Re: Optimize mul_var() for var1ndigits >= 8 |
Previous Message | Ilia Evdokimov | 2024-08-12 10:42:07 | Add support for (Var op Var) clause in extended MCV statistics |