Re: cleaning perl code

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: "Hamlin, Garick L" <ghamlin(at)isc(dot)upenn(dot)edu>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cleaning perl code
Date: 2020-04-16 14:34:39
Message-ID: b4d73727-801a-283e-4773-11885542fcbc@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 4/16/20 10:20 AM, Hamlin, Garick L wrote:
> On Thu, Apr 16, 2020 at 08:50:35AM -0400, Andrew Dunstan wrote:
>> It would also be more robust using non-greedy matching:
> This seems more important.
> I don't know how/where this is being used, but if it has input like:
>
> /* one */
> something;
> /* two */
>
> With the old expression 'something;' would be stripped away.
> Is that an issue where this this is used? Why are we parsing
> these headers?
>

It's not quite as bad as that, because we're doing it line by line
rather than on a whole file that's been slurped in. Multiline comments
are handled using some redo logic. But

    /* one */ something(); /* two */

would all be removed. Of course, we hope we don't have anything so
horrible, but still ...

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-16 14:43:13 Re: Poll: are people okay with function/operator table redesign?
Previous Message Hamlin, Garick L 2020-04-16 14:20:53 Re: cleaning perl code