From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Tighten up a few overly lax regexes in pg_dump's tap tests |
Date: | 2019-02-05 01:41:19 |
Message-ID: | 20190205014119.GB1882@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 05, 2019 at 01:50:50PM +1300, David Rowley wrote:
> I think I've done all the ones that use \E. Those \Q ones don't need
> any escaping. I assume that's the ones you've found. I didn't do an
> exhaustive check though.
Oh, good point. I didn't know that anything between \Q and \E are
interpreted as literal characters. Instead of the approach you are
proposing, perhaps it would make sense to extend this way of doing
things then? For example some tests with CREATE CONVERSION do so. It
looks much more portable than having to escape every dot.
>> test_pg_dump's 001_base.pl needs also a refresh.
>
> Yeah, I thought about looking, but I thought it might be a bottomless pit.
I just double-checked this one, and the regex patterns there look
all correct.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2019-02-05 02:40:35 | RE: Protect syscache from bloating with negative cache entries |
Previous Message | David Rowley | 2019-02-05 00:50:50 | Re: Tighten up a few overly lax regexes in pg_dump's tap tests |