Andres Freund writes:
> On 2024-04-15 20:47:16 -0400, Tom Lane wrote:
>> Ah, thanks. I guess this depends on getopt_long reordering arguments
>> (since the "-o outfile" bit will come later). That is safe enough
>> in HEAD since 411b72034, but it might fail on weird platforms in v16.
>> How much
Hi,
On 2024-04-15 20:47:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-04-15 17:48:32 -0400, Tom Lane wrote:
> >> But I have no idea about making it work in meson. Any suggestions?
>
> > So you just want to compile define.c twice? The below should suffice:
>
> > - 'define':
d8119771ecba38bb51951d Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Mon, 15 Apr 2024 20:37:50 -0400
Subject: [PATCH v2] Fix assorted bugs in ecpg's macro mechanism.
The code associated with EXEC SQL DEFINE was unreadable and full of
bugs, notably:
* it'd attempt to free a non-malloced strin
Hi,
On 2024-04-15 17:48:32 -0400, Tom Lane wrote:
> I started looking into the ideas discussed at [1] about reimplementing
> ecpg's string handling. Before I could make any progress I needed
> to understand the existing input code, part of which is the macro
> expansion mechanism ... and the
n, 15 Apr 2024 17:33:30 -0400
Subject: [PATCH v1] Fix assorted bugs in ecpg's macro mechanism.
The code associated with EXEC SQL DEFINE was unreadable and full of
bugs, notably:
* it'd attempt to free a non-malloced string if the ecpg program
tries to redefine a macro that was defined on the com