Huansong Fu writes:
> We recently saw a similar issue in v12 and wondered why the corresponding fix
> for v14 (https://github.com/postgres/postgres/commit/16e3ad5d143) was not
> backported to v13 and before. The commit message did mention that this fix
> might have problem with translatable str
Hi,
We recently saw a similar issue in v12 and wondered why the corresponding fix
for v14 (https://github.com/postgres/postgres/commit/16e3ad5d143) was not
backported to v13 and before. The commit message did mention that this fix
might have problem with translatable string messages - would yo
Quan Zongliang writes:
> I tested it, and it looks fine.
Pushed, thanks for reporting the issue!
regards, tom lane
Good.
I tested it, and it looks fine.
Thank you.
On 2020/6/29 1:10 上午, Tom Lane wrote:
I wrote:
Even granting the premise, the proposed patch seems like a significant
decrease in user-friendliness for typical cases. I'd rather see us
make an effort to print one valid-per-the-DB-encoding cha
I wrote:
> Even granting the premise, the proposed patch seems like a significant
> decrease in user-friendliness for typical cases. I'd rather see us
> make an effort to print one valid-per-the-DB-encoding character.
> Now that we can rely on snprintf to count %s restrictions in bytes,
> I think
Quan Zongliang writes:
> The reason is that the error message in the bit_in / varbit_in function
> is output directly using %c. Causes the log file to not be decoded
> correctly.
> The attachment is a patch.
I'm really quite skeptical of the premise here. We do not guarantee that
the postmast
The bit/varbit type input functions cause file_fdw to fail to read the
logfile normally.
1. Server conf:
server_encoding = UTF8
locale = zh_CN.UTF-8
2. Create external tables using file_fdw
CREATE EXTENSION file_fdw;
CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN
