[Pgsql-ayuda] Funció n validadora tal vez demasiado ambiciosa

[Alvaro Herrera]

On Mon, Jun 16, 2003 at 05:44:34PM -0500, Gunnar Wolf wrote:

Gunnar,

> Estoy atorado con una idea que tuve, espero que me puedan echar una
> mano. Estoy participando en la creación de un sistema para manejo de
> congresos que espero pueda ser muy adecuable para las necesidades de
> quien se lo encuentre. Tengo una duda que no encuentro por dónde
> pegarle - Uso este correo un poco para pensar en voz alta, un poco para
> pedir su ayuda:

Leí el thread completo antes de volver acá.  La verdad, me parece
extraño que quieras modificar el esquema de la BD "en producción".  Si
bien es fácil ver que durante el "desarrollo" la BD va a cambiar, en
algún momento deberías cortar y quedarte con un cierto diseño.

En particular, si para un congreso se define que los expositores tienen
mail obligatorio, ese requisito no se cambia a mitad del congreso...


> En mi esquema estoy definiendo ciertos campos como completamente
> opcionales (por ejemplo, la organización y departamento a que pertenece
> una persona) y ciertos campos como completamente requeridos (por
> ejemplo, el nombre propio de una persona). Los campos opcionales deben
> aceptar valores NULL.

Y ya que estamos, por qué no puede ser que ciertos campos deben existir
para algunos congresos y no para otros?


> Hay, sin embargo, otros campos que dependiendo de la configuración serán
> obligatorias o no - Por ejemplo, el email. Para ciertos congresos es
> información indispensable, mientras que para otros no. 

A ver, vas a tener varios congresos en la misma base de datos, o cada
uno tendrá una separada?  Porque si son todas juntas entonces no hay
manera de ponerle el NOT NULL, mientras que si son separadas entonces le
das ALTER TABLE ... (SET|DROP) NOT NULL y no necesitas configurar nada.


> INSERT INTO config (name, value) VALUES ('person.email.allow_null','1');
> 
> y controlar por medio de una función invocada por trigger cada uno de
> los campos configurables.
> 
> Esta tal vez sería una idea bonita, pero muy cara - Imaginemos que en la
> tabla person haya 5 campos configurables - cada INSERT o UPDATE
> implicaría un costo de cinco SELECTs adicionales.

Otra alternativa sería poner la "nulabilidad" en el comentario de cada
columna, y hacer el chequeo via un trigger escrito en C que revise el
comentario.  Es horrible, pero seguramente tiene mejor rendimiento :-)
Puedes obtenerlo todo junto con una sola consulta, porque todos los
comentarios salen de la tabla pg_catalog.pg_description.

O bien darle campos de tipo OID a la tabla config para la nulabilidad y
usar el mismo mecanismo de pg_description, o sea
CREATE TABLE config_nulls (
	tabla	oid,
	columna num,		-- de "pg_catalog.pg_attribute.attnum"
	nulls	boolean
);

Tienes alguna otra cosa que deba ser configurable?  Yo sospecho que esto
debería ser resuelto condición por condición.  Una tabla "config" es
demasiado general... algún día querrás hacer el tipo de cada columna
configurable y ahí sí que te metes en líos :-(


> SELECT allow_null_values('person','email',1);

Hum... cual es la diferencia con hacer el ALTER TABLE directamente?  Es
más cuestión de hacer que el frontend reaccione adecuadamente al click
sobre el botón.


> Otra: ¿Se les ocurre alguna manera de convertir una cadena 'person' en
> el identificador de la tabla person?

Como ya dijo Manuel, pásalo por regclass.

Suerte, y regresa con tus conclusiones.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Si quieres ser creativo, aprende el arte de perder el tiempo"