Re: confusing / inefficient "need_transcoding" handling in copy
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Sutou Kouhei <kou@clear-code.com>, Tatsuo Ishii <ishii@sraoss.co.jp>
Date: 2024-02-09T00:36:28Z
Lists: pgsql-hackers
On Thu, Feb 08, 2024 at 10:25:07AM +0200, Heikki Linnakangas wrote: > There's no validation, just conversion. I'd suggest: > > "Set up encoding conversion info if the file and server encodings differ > (see also pg_server_to_any)." > > Other than that, +1 Cool. I've used your wording and applied that on HEAD. > BTW, I can see an optimization opportunity even if the encodings differ: > Currently, CopyAttributeOutText() calls pg_server_to_any(), and then grovels > through the string to find any characters that need to be quoted. You could > do it the other way round and handle quoting before the conversion. That has > two benefits: > > 1. You don't need the strlen() call, because you just scanned through the > string so you already know its length. > 2. You don't need to worry about 'encoding_embeds_ascii' when you operate on > the server encoding. That sounds right, still it looks like there would be cases where you'd need the strlen() call if !encoding_embeds_ascii. -- Michael
Commits
-
Add some tests for encoding conversion in COPY TO/FROM
- 3ad8b840ce8b 18.0 landed
-
Improve COPY TO performance when server and client encodings match
- b619852086ed 17.0 landed