Re: Missing [NO] INDENT flag in XMLSerialize backward parsing - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Missing [NO] INDENT flag in XMLSerialize backward parsing
Date
Msg-id 6d146918-dbd6-4de2-bdd1-80471c1e0053@uni-muenster.de
Whole thread Raw
In response to Re: Missing [NO] INDENT flag in XMLSerialize backward parsing  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Missing [NO] INDENT flag in XMLSerialize backward parsing
List pgsql-hackers
Hi Michael & Andrew

On 21.02.25 11:46, Andrew Dunstan wrote:
>> On Feb 21, 2025, at 4:55 AM, Michael Paquier <michael@paquier.xyz> wrote:
>>
>> On Fri, Feb 21, 2025 at 04:36:07AM -0500, Andrew Dunstan wrote:
>>> The fix has broken cross version upgrade test. Maybe we need to filter out
>>> NO INDENT in releases prior to 16 in AdjustUpgrade.pm?s
>> Yes, I was just looking at that.  The regex I am finishing with in
>> AdjustUpgrade.pm is something like that, which is enough to discard
>> the NO INDENT clause in an XMLSERIALIZE:
>> --- src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm
>> +++ src/test/perl/PostgreSQL/Test/AdjustUpgrade
>> @@ -628,6 +628,12 @@ sub adjust_new_dumpfile
>>                        \s+FUNCTION\s2\s\(text,\stext\)\spublic\.part_hashtext_length\(text,bigint\);} {}mxg;
>>    }
>>
>> +    # pre-v16 dumps do not know about XMLSERIALIZE(NO INDENT).
>> +    if ($old_version < 16)
>> +    {
>> +        $dump =~ s/XMLSERIALIZE\((.*)? NO INDENT\)/XMLSERIALIZE\($1\)/mg;
>> +    }
>>
>> This needs to be applied in adjust_new_dumpfile() so as the comparison
>> with the old dump will be stable, is that right?
> I think so. Looks good to me 


Thanks for the quick response!

For future reference, what’s the best way to verify this myself? The
buildfarm was all green.

Best regards, Jim




pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Next
From: Jim Jones
Date:
Subject: Re: [PoC] XMLCast (SQL/XML X025)