Re: Reporting script runtimes in pg_regress - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Reporting script runtimes in pg_regress
Date
Msg-id 20190308130234.GD11419@msg.df7cb.de
Whole thread Raw
In response to Re: Reporting script runtimes in pg_regress  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Reporting script runtimes in pg_regress
List pgsql-hackers
Re: Peter Eisentraut 2019-03-08 <3eb194cf-b878-1f63-8623-6d6add0ed0b7@2ndquadrant.com>
> On 2019-02-21 10:37, Christoph Berg wrote:
> > diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
> > index a18a6f6c45..8080626e94 100644
> > --- a/src/test/regress/pg_regress.c
> > +++ b/src/test/regress/pg_regress.c
> > @@ -1794,12 +1794,14 @@ run_schedule(const char *schedule, test_function tfunc)
> >                  else
> >                  {
> >                      status(_("FAILED"));
> > +                    status("          "); /* align with failed (ignored) */
> >                      fail_count++;
> >                  }
> 
> So an issue here is that in theory "FAILED" etc. are marked for
> translation but your spacers do not take that into account.  Personally,
> I have no ambition to translate pg_regress, so we could remove all that.
>  But it should be done consistently in either case.

Oh, right. So the way to go would be to use _("FAILED       "), and
ask translators to use the same length.

> I also think we shouldn't worry about the "failed (ignored)" case.  That
> never happens, and I don't want to mess up the spacing we have now for
> that.  I'd consider removing support for it altogether.

You mean removing that case from pg_regress, or removing the alignment
"support"?

Christoph


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_basebackup ignores the existing data directory permissions
Next
From: Amit Langote
Date:
Subject: Re: Is it too soon for a PG12 open items wiki page?