| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add find_in_log() and advance_wal() perl functions to core test framework (?) |
| Date: | 2022-08-16 16:40:49 |
| Message-ID: | 20220816164049.z7rmzkvmm2dloep7@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022-Aug-16, Andrew Dunstan wrote:
> I don't think there's a hard and fast rule about it. Certainly the case
> would be more compelling if the functions were used across different TAP
> suites. The SSL suite has suite-specific modules. That's a pattern also
> worth considering. e.g something like.
>
> use FindBin qw($Bin);
> use lib $Bin;
> use MySuite;
>
> and then you put your common routines in MySuite.pm in the same
> directory as the TAP test files.
Yeah, I agree with that for advance_wal. Regarding find_in_log, that
one seems general enough to warrant being in Cluster.pm -- consider
issues_sql_like, which also slurps_file($log). That could be unified a
little bit, I think.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2022-08-16 16:52:11 | Re: SYSTEM_USER reserved word implementation |
| Previous Message | Robert Haas | 2022-08-16 16:34:23 | pg_walinspect: ReadNextXLogRecord's first_record argument |