>
> On 21.03.22 15:37, Aleksander Alekseev wrote:
> >> It would not simplify things for them at all, just mess it up.
> >> The master copies of the .po files are kept in a different repo.
> >> Also, I believe that extraction of new message strings is automated
> >> already.
> >
> > Got it, thanks.
On 21.03.22 15:37, Aleksander Alekseev wrote:
It would not simplify things for them at all, just mess it up.
The master copies of the .po files are kept in a different repo.
Also, I believe that extraction of new message strings is automated
already.
Got it, thanks. Here is the corrected patch.
Aleksander Alekseev writes:
> Got it, thanks. Here is the corrected patch. It includes all the
> changes by me and Japin, and doesn't touch PO files.
Pushed. I removed now-unnecessary braces, reflowed some lines
as suggested by Pavel, and pgindent'ed (which insisted on adding
spaces after the ca
Hi Tom,
> It would not simplify things for them at all, just mess it up.
> The master copies of the .po files are kept in a different repo.
> Also, I believe that extraction of new message strings is automated
> already.
Got it, thanks. Here is the corrected patch. It includes all the
changes by
Aleksander Alekseev writes:
>> As Tom said in [1], we don't need to touch the *.po files, since those
>> files are managed by the translation team.
> True, but I figured that simplifying the work of the translation team would
> not harm either.
It would not simplify things for them at all, just
Hi Japin,
> As Tom said in [1], we don't need to touch the *.po files, since those
files
> are managed by the translation team.
>
> [1]
https://www.postgresql.org/message-id/1110708.1647623560%40sss.pgh.pa.us
True, but I figured that simplifying the work of the translation team would
not harm eit
Hi Japin,
> After apply the patch, I found pg_checksums.c also has the similar code.
Thanks for noticing it.
> In progress_report(), I'm not sure we can do this replace for this code.
I added the corresponding change as a separate commit so it can be
easily reverted if necessary.
Here is a com
On Mon, 21 Mar 2022 at 17:23, Aleksander Alekseev
wrote:
> Hi Pavel,
>
>> Probably you can do (long long) instead of (long long int). It is shorter
>> and this is used elsewhere in the code.
>
> Thanks! Here is the updated patch. I also added Reviewed-by: and
> Discussion: to the commit message
>
> > Probably you can do (long long) instead of (long long int). It is
> shorter and this is used elsewhere in the code.
>
> Thanks! Here is the updated patch. I also added Reviewed-by: and
> Discussion: to the commit message.
>
Thanks, Alexander!
I suggest the patch is in a good shape to be commi
Hi Pavel,
> Probably you can do (long long) instead of (long long int). It is shorter and
> this is used elsewhere in the code.
Thanks! Here is the updated patch. I also added Reviewed-by: and
Discussion: to the commit message.
--
Best regards,
Aleksander Alekseev
v2-0001-Remove-workarounds-
пн, 21 мар. 2022 г. в 12:52, Aleksander Alekseev :
> Hi hackers,
>
> I learned from Tom [1] that we can simplify the code like:
>
> ```
> char buff[32];
> snprintf(buf, sizeof(buf), INT64_FORMAT, ...)
> ereport(WARNING, (errmsg("%s ...", buf)));
> ```
>
> ... and rely on %lld/%llu now as long as w
Hi hackers,
I learned from Tom [1] that we can simplify the code like:
```
char buff[32];
snprintf(buf, sizeof(buf), INT64_FORMAT, ...)
ereport(WARNING, (errmsg("%s ...", buf)));
```
... and rely on %lld/%llu now as long as we explicitly cast the
argument to long long int / unsigned long long. T
12 matches
Mail list logo
