mirror of
https://github.com/postgres/postgres.git
synced 2025-07-26 01:22:12 +03:00
config
contrib
adminpack
auth_delay
auto_explain
btree_gin
btree_gist
chkpass
citext
cube
dblink
dict_int
dict_xsyn
dummy_seclabel
earthdistance
file_fdw
fuzzystrmatch
hstore
intagg
intarray
isn
lo
ltree
oid2name
pageinspect
passwordcheck
pg_archivecleanup
pg_buffercache
pg_freespacemap
pg_prewarm
pg_standby
pg_stat_statements
Makefile
pg_stat_statements--1.0--1.1.sql
pg_stat_statements--1.1--1.2.sql
pg_stat_statements--1.2.sql
pg_stat_statements--unpackaged--1.0.sql
pg_stat_statements.c
pg_stat_statements.control
pg_test_fsync
pg_test_timing
pg_trgm
pg_upgrade
pg_upgrade_support
pg_xlogdump
pgbench
pgcrypto
pgrowlocks
pgstattuple
postgres_fdw
seg
sepgsql
spi
sslinfo
start-scripts
tablefunc
tcn
test_decoding
test_parser
test_shm_mq
tsearch2
unaccent
uuid-ossp
vacuumlo
worker_spi
xml2
Makefile
README
contrib-global.mk
doc
src
.dir-locals.el
.gitattributes
.gitignore
COPYRIGHT
GNUmakefile.in
HISTORY
Makefile
README
README.git
aclocal.m4
configure
configure.in
769065c1b2
A large majority of the callers of pg_do_encoding_conversion were specifying the database encoding as either source or target of the conversion, meaning that we can use the less general functions pg_any_to_server/pg_server_to_any instead. The main advantage of using the latter functions is that they can make use of a cached conversion-function lookup in the common case that the other encoding is the current client_encoding. It's notationally cleaner too in most cases, not least because of the historical artifact that the latter functions use "char *" rather than "unsigned char *" in their APIs. Note that pg_any_to_server will apply an encoding verification step in some cases where pg_do_encoding_conversion would have just done nothing. This seems to me to be a good idea at most of these call sites, though it partially negates the performance benefit. Per discussion of bug #9210.