Re: ECPG cleanup and fix for clang compile-time problem

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.

In response to

Responses

Browse pgsql-hackers by date

  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