set_config(‘search_path’) does not truncate names over 63 bytes, unlike SET

*PostgreSQL version:* 18.6
*Operating system:* Debian 13 (official postgres:18 Docker image), x86_64

*Short description:*
search_path set via set_config() keeps names longer than NAMEDATALEN-1
untruncated, unlike SET

Details:

When search_path is set with set_config(), a schema name longer than 63
bytes
(NAMEDATALEN - 1) is stored and reported in full, but a truncated name is
used
for lookup. SET truncates the same name up front and raises a NOTICE. So
SHOW / current_setting() / pg_settings report a value that differs from the
one
actually in effect, with no notice.

Repro:

CREATE SCHEMA
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; --
70 chars
-- NOTICE: identifier "aaa...(70)" will be truncated to "aaa...(63)"

SELECT set_config('search_path', repeat('a', 70) || ', public', false);
-- no NOTICE
SHOW search_path; -- aaa...(70), public
SELECT current_setting('search_path'); -- aaa...(70), public
SELECT current_schemas(false); -- {aaa...(63),public}
CREATE TABLE t (i int); -- created in schema aaa...(63)

SET search_path =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
public;
-- NOTICE: identifier "aaa...(70)" will be truncated to "aaa...(63)"
SHOW search_path; -- aaa...(63), public

The truncation at use time happens in SplitIdentifierString() (called from
check_search_path() and recomputeNamespacePath()), which works on a copy, so
the stored string keeps the full name.

Expected: the two ways of setting search_path should agree. Either
set_config() / check_search_path() store the truncated names (as SET does),
or at least raise the same NOTICE when a name will be truncated. As it is,
an application that reads back current_setting('search_path') sees a value
that isn't the one in effect.

The same applies to other list GUCs split with SplitIdentifierString(),
such as
temp_tablespaces.