jvenegasperu . escribió:
> El 4 de diciembre de 2017, 13:42, Alvaro Herrera <alvhe...@alvh.no-ip.org>
> escribió:
> > Lo que realmente te hace falta, creo, es una restriccion EXCLUDE, que
> > debería ser algo así:
> >
> > ALTER TABLE ap_valvula ADD CONSTRAINT no_misma_geom
> > EXCLUDE (the_geom WITH ~=);
> >
> > Quizás alguien pueda proveer un ejemplo más completo (yo no tengo
> > postgis disponible aquí); pero la idea es que no usas triggers ni reglas
> > sino que la restricción misma se hace cargo del problema.
>
> Alvaro es posible que la restriccion use menos recursos y por ende sea una
> solución mas optima?
Seguro.
> > Ahora, tu regla no *impide* que se inserte el objeto (yo esperaría que
> > eso arrojara un error), sino que más bien no inserta nada cuando el
> > insert va a una geometría donde ya hay un objeto. Usando EXCLUDE va a
> > arrojar un error.
>
> Tienes razon Alvaro la razon por la que la regla solo devolvia Null era
> porque yo la usaba cuando migraba datos en batch y eran miles y a mi
> simplemente me interesaba que no se dupliquen sin avisar del error
> simplemente se descartaban duplicados.
Ok.
> Usandola desde QGIs estaba funcionando bien hasta que en la version 2.18.
> dejo de funcionar enviando el error
>
> "Necesita un regla incondicional ON INSERT DO INSTEAD con una cláusula
> RETURNING"
De QGIS no tengo idea.
> Eso me lleva a pensar que si implemento la restricción y despues quiero
> importar datos tendre que quitarla temporalmente porque la excepcion
> paralizaria el trabajo?.
No creo que la idea de quitar y poner restricciones sea operacionalmente
lo mejor. Considera la idea que te sugiero: en vez de que la aplicación
haga INSERT directamente, usa una función en plpgsql que tenga un bloque
algo así como
BEGIN
INSERT INTO ... ( ... )
EXCEPTION WHEN EXCLUSION_VIOLATION THEN
RAISE NOTICE 'no insertamos nada porque ya había algo';
RETURN NULL;
END
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
