Pour le ALTER COLUMN vous pouvez metttre USING NULL s'il n'y avait pas de contenu avant ou s'il est intraduisible dans le nouveau type.

Le problème c'est que le search_path pointe sur un schéma qui n'existe pas du fait d'un pb de syntaxe.
Il a été positionné avec une commande du style:

SET search_path TO "edbuser,edbstore";

alors qu'il aurait dû être mis comme ça:

SET search_path TO edbuser, edbstore;

ou comme ça (avec guillemets même s'ils ne servent à rien ici puisque tout est en minuscules et acvec des caractères de base)

SET search_path TO "edbuser" , "edbstore";

Si je comprends l'objectif, l'opération que vous voulez faire est un UPDATE, pas un INSERT.
Un INSERT c'est uniquement pour insérer une nouvelle ligne, donc un nouveau département si on parle
d'une table où il y a une ligne par département.

Ici après avoir ajouté une colonne nomregion par ALTER TABLE, il s'agirait plutôt de mettre à jour le contenu
de cette colonne pour chaque département pré-existant.

La requête doit être du style:

UPDATE  departements  SET nomregion =
  (SELECT regions.nomregions
    FROM regions
   WHERE  ST_CONTAINS(regions.geom, departements.geom)
 );

Le SELECT entre parenthèses est une sous-requête corrélée, c'est-à-dire que pour chaque ligne de departements, le moteur va l'exécuter avec la valeur de departements.geom correspondant à cette ligne-là, et va mettre à jour le nomregion de cette ligne-là avec le résultat correspondant.

C'est complètement normal, linux garde les blocs en cache, déjà parce qu'ils ne sont pas encore nécessairement écrits physiquement sur le disque, et parce que de toute façon  la mémoire qui ne sert à rien d'autre a tendance à être utilisée en cache.

Si vous voulez vider le cache, faire en tant que root:

  sync && echo 3 > /proc/sys/vm/drop_caches

Ce n'est pas la peine de mettre une contrainte via CHECK pour la longueur car un champ typé  VARCHAR(5) par exemple a déjà une contrainte sur le non-dépassement de 5 caractères.
Sinon oui c'est judicieux de remplacer CHAR(n) par VARCHAR(n). CHAR(n) complète avec des blancs à droite qui prennent de la place et n'ont aucun intérêt.

Ce résultat, s'il est obtenu sur une colonne déclarée CHAR(10), prouve à 100% que vous avez des caractères qui ne sont ni des blancs ni des chiffres qui ont atterri dans le champ.

Pour voir exactement ce que sont ces caractères y compris s'ils sont invisibles à l'écran,
vous pouvez exécuter ce genre de requête qui extrait les caractères un par un avec leur code numérique:

select r,ascii(r) from
  (select regexp_split_to_table(code, '') as r from BD.TABLE where octet_length(code)=12) s;

C'est faisable et courant mais pour ça il faut utiliser le dépôt pgdg comme expliqué ici:

https://wiki.postgresql.org/wiki/Apt

Est-ce que ça ne revient pas à demander si Postgres est capable de gérer sa fonctionnalité de "surcharge" dans tous les cas? La réponse est oui, sinon on serait bien embêtés.
Il est vrai que si on prend tout en compte: cast implicites de types en d'autres types, arguments "variadiques", valeurs par défaut, ordre de priorités du search_path, arguments IN et OUT, l'algorithme qui doit trouver la bonne fonction est complexe, mais à ma connaissance il est  totalement déterministe.

Ce bloc fait une erreur pour moi:

ERROR:  record "r" has no field "oid"
CONTEXT:  SQL statement "Select pg_get_function_arguments (f.oid)           from pg_proc f where f.oid = r.oid"
PL/pgSQL function inline_code_block line 23 at SQL statement

ce qui est logique puisque r est alimenté par
  FOR r IN SELECT p.proname, p.proowner, p.pronamespace
             FROM pg_proc p

et qu'il n'y a pas d'oid derrière ce SELECT, il faut justement l'ajouter.

select '{"a":1, "b":2, "a":3}'::jsonb;
      jsonb       
------------------
 {"a": 3, "b": 2}

Avec le type jsonb, la valeur 1 pour la clef "a" est éliminée par la seconde valeur 3 pour la même clef.

Par opposition, voilà ce que ça donne avec le type json où toutes les valeurs sont conservées:

select '{"a":1, "b":2, "a":3}'::json;
         json          
-----------------------
 {"a":1, "b":2, "a":3}
(1 row)

Typiquement on a ce genre d'erreur quand une même connexion est multi-utilisée par différents threads ou processus fils d'un même programme client. C'est interdit. Chaque thread doit utiliser sa propre connexion, ou au pire un système d'exclusion mutuelle parfaitement au point pour éviter les conflits.

Le forum est là pour ça
N'oubliez pas de préciser les versions de vos logiciels avec les questions.