SELECT Probe_Geometry_Columns();
est un utilitaire pratique.
Tout d'abord, lorsque nous ajoutons une colonne de géométrie à une table existante avec
SELECT AddGeometryColumn('my_table', 'geo_column', 1234, 'MULTIPOINT', 2);
nous alimentons la fonction tout ce dont elle a besoin pour clouer la colonne de type géométrie (geo_column) dans la table spécifiée (my_table) et écrire les détails importants comme SRID (1234), type de géométrie (MULTIPOINT) et nombre de dimensions (2) pour la table geometry_columns. En substance, c'est un ALTER et trois UPDATES.
La création de colonnes de géométrie par d'autres moyens (chargées à partir d'un fichier de formes, sélectionnées dans un CREATE TABLE AS, etc.) peut conduire à des tables spatiales invisibles pour les applications externes, bien qu'elles fonctionnent très bien dans la base de données. Sans les bons détails stockés dans geometry_columns, les valeurs de géométrie réelles apparaissent sous forme de chaînes de caractères absurdes pour les applications à la recherche de points, lignes ou polygones projetés.
L'appel de la fonction de sonde vérifie chaque colonne de type geometry, ajoutant de nouvelles valeurs à geometry_columns et signalant les conflits.
En revenant à votre question, GeoServer ne pense pas que la table renommée contient des données spatiales si le changement de nom n'est pas reflété dans geometry_columns. Une autre chose à considérer est que la fonction de sonde crée un enregistrement en double reflétant le nouveau nom de la table mais ne se débarrasse pas de l'enregistrement d'origine - un autre blocage potentiel pour GeoServer.
Cela dit, je vous suggère: 1) d'exécuter la sonde puis de supprimer immédiatement l'ancien enregistrement; ou 2) suivez votre changement de nom avec un ALTER sur geometry_columns pour changer la valeur f_table_name.
Désolé pour la verbosité, mais j'espère que cela aide.