On Thu, Dec 12, 2024 at 03:25:41PM +0900, Sutou Kouhei wrote: > In <z1fkrtkt-eiva...@paquier.xyz> > "Re: confusing / inefficient "need_transcoding" handling in copy" on Tue, > 10 Dec 2024 13:59:25 +0900, > Michael Paquier <mich...@paquier.xyz> wrote: >> Another one would be valid conversions back and forth. For example, >> I recall that LATIN1 accepts any bytes and can apply a conversion to >> UTF-8, so we could use it and expand a bit more the proposed tests? >> Or something like that? > > OK. I've added valid cases too by using LATIN1 as you > suggested.
I may have missed something but v3 does not use that for a valid conversion? >> Likely, this should be made conditional, based on the fact that the >> database needs to be able to support utf8? There are a couple of >> examples like that in the tree, based on the following SQL trick: >> SELECT getdatabaseencoding() <> 'UTF8' AS skip_test \gset >> \if :skip_test >> \quit >> \endif > > Thanks. I didn't notice the portability problem. I've added > the skip trick. Indeed, thanks. > Oh! I didn't know the "XXX_1.out" feature. You have missed the inclusion of an alternate output, which should be something like that to bypass the test rather than failing: --- /dev/null +++ b/src/test/regress/expected/copyencoding_1.out @@ -0,0 +1,7 @@ +-- +-- Test cases for COPY encoding +-- +-- skip test if not UTF8 server encoding +SELECT getdatabaseencoding() <> 'UTF8' AS skip_test \gset +\if :skip_test +\quit I guess that you have the file, forgot a `git add`. -- Michael
signature.asc
Description: PGP signature
