PostgreSQL 9.5: entrée de clause FROM manquante pour la table "new"

Question

J'ai vu beaucoup de messages comme le mien, mais je n'ai pas réussi à trouver une réponse appropriée à ma situation, qui devrait être basique je présume. J'utilise l'extension PostGIS 2.3. Voici mon code:

CREATE OR REPLACE FUNCTION public.split_cable() 
    RETURNS trigger AS 
$BODY$ 
DECLARE geometrie geometry; 
BEGIN  
geometrie = new.geom;  
create view temp_wire as (
    with brs as (select boite.geom from cablage_pays_gex.boite 
    where st_intersects(boite.geom, new.geom) and boite.geom not in (select st_startpoint(st_linemerge(new.geom))) and boite.geom not in (select st_endpoint(st_linemerge(new.geom))) 
    ) 
    select st_dump(st_split(new.geom, brs.geom)) from brs 
    ); 
RETURN new; 
END 
$BODY$ 
    LANGUAGE plpgsql VOLATILE; 

Comme vous pouvez le voir, j'ai une variable « geometrie » que je ne l'utilise, c'est parce que j'ai essayé de déclarer une variable contenant les données que je veux utiliser, sans succès. L'erreur que j'obtiens est celle qui titille ma question, et elle pointe vers la fonction st_intersects() (donc la première fois que j'essaie d'appeler le nouveau .geom). Qu'est-ce que je fais mal? Et comment puis-je résoudre cela?

EDIT: Voici la déclaration create table sur laquelle le déclencheur agit:

CREATE TABLE public.cable2 
(
    id_cable integer NOT NULL DEFAULT nextval('cable2_seq'::regclass), 
    geom geometry(MultiLineString,2154), 
    CONSTRAINT cable2_pkey PRIMARY KEY (id_cable) 
); 

Answer 1

TL; DR: dynamique SQL est nécessaire pour la déclaration CREATE VIEW.

Dans plpgsql, les variables ne sont pas interpolées dans les requêtes de définition de données, comme les requêtes CREATE....

Plus généralement, le plpgsql documentation dit comme:

Les paramètres ne seront remplacés dans des endroits où un paramètre ou une référence colonne est syntaxiquement permis

Et dans les requêtes DDL, le lieu où ils sont autorisés est: nulle part.

C'est pourquoi la référence new.geom dans votre requête est prise littéralement, et pourquoi le transférer dans une variable temporaire geometrie ne la ferait pas mieux fonctionner.

Le SQL dynamique consiste essentiellement à créer une chaîne de commande, puis à exécuter cette chaîne comme une instruction avec EXECUTE. Cette chaîne, une fois générée, ne doit plus contenir de référence aux variables. Plus d'informations dans le doc: Executing Dynamic Commands

Indépendamment de cela, comme indiqué dans les commentaires, créer une vue permanente chaque fois qu'une ligne est affectée dans un tableau semble complètement faux, au niveau conceptuel. Il est difficile de comprendre pourquoi vous voulez le faire en premier lieu.