Tom Lane 769065c1b2 Prefer pg_any_to_server/pg_server_to_any over pg_do_encoding_conversion. ... 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.		2014-02-23 16:59:05 -05:00
..
Makefile
pg_stat_statements--1.0--1.1.sql
pg_stat_statements--1.1--1.2.sql	Keep pg_stat_statements' query texts in a file, not in shared memory.	2014-01-27 15:37:54 -05:00
pg_stat_statements--1.2.sql	Keep pg_stat_statements' query texts in a file, not in shared memory.	2014-01-27 15:37:54 -05:00
pg_stat_statements--unpackaged--1.0.sql
pg_stat_statements.c	Prefer pg_any_to_server/pg_server_to_any over pg_do_encoding_conversion.	2014-02-23 16:59:05 -05:00
pg_stat_statements.control