Re: Tighten up a few overly lax regexes in pg_dump's tap tests

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Tighten up a few overly lax regexes in pg_dump's tap tests
Дата
Msg-id 7260BBB4-0E01-4D64-A31D-A8456B40CF12@yesql.se
обсуждение исходный текст
Ответ на Re: Tighten up a few overly lax regexes in pg_dump's tap tests  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
> On 5 Feb 2019, at 06:55, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Monday, February 4, 2019, David Rowley <david.rowley@2ndquadrant.com <mailto:david.rowley@2ndquadrant.com>> wrote:
> On Tue, 5 Feb 2019 at 01:12, Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:
> > We may also want to use the + metacharacter instead of * in a few places, since
> > the intent is to always match something, where matching nothing should be
> > considered an error:
> >
> > -                 qr/^ALTER TEXT SEARCH DICTIONARY dump_test.alt_ts_dict1 OWNER TO .*;/m,
> > +                 qr/^ALTER TEXT SEARCH DICTIONARY dump_test\.alt_ts_dict1 OWNER TO .*;/m,
>
> I looked for instances of * alone and didn't see any. I only saw ones
> prefixed with ".", in which case, isn't that matching 1 or more chars
> already?
>
> No.  In Regex the following are equivalent:
>
> .* == .{0,}
> .+ == .{1,}
> . == .{1}
>
> A “*” by itself would either be an error or, assuming the preceding character is a space (so it visually looks alone)
wouldbe zero or more consecutive spaces. 

Sorry for being a bit unclear in my original email, it’s as David says above:
.* matches zero or more characters and .+ matches 1 or more characters.

> In the above “...OWNER TO<space>;” is a valid match.

Indeed, so we should move to matching with .+ to force an owner.

cheers ./daniel

В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: WIP: Avoid creation of the free space map for small tables
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Online verification of checksums