Re: Bugs in ecpg's macro mechanism

2024-04-15 Thread Tom Lane
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

Re: Bugs in ecpg's macro mechanism

2024-04-15 Thread Andres Freund
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':

Re: Bugs in ecpg's macro mechanism

2024-04-15 Thread Tom Lane
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

Re: Bugs in ecpg's macro mechanism

2024-04-15 Thread Andres Freund
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

Bugs in ecpg's macro mechanism

2024-04-15 Thread Tom Lane
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