¿Hay funciones SQL estándar con efectos secundarios?

¿Los estándares SQL definen funciones con efectos secundarios?

Por ejemplo, ¿tienen funciones para escribir en archivos * o para actualizar valores en ciertas columnas de una tabla cuando haces algo como

SELECT myfunction(params...);

He visto esto a veces, pero tengo curiosidad por saber si los estándares SQL hacen lo mismo.

_{* Esta no es una pregunta sobre PostgreSQL específicamente. Solo estoy usando los ejemplos de efectos secundarios que veo en PostgreSQL.}

Tienes algunas preguntas diferentes aquí.

P: ¿Cuáles son las funciones SQL estándar de ANSI?

Las funciones estándar ANSI son cosas como AVG, COUNT, MIN, MAX. Están cubiertos por el estándar ANSI de 1992 , pero esa es una lectura seca y aburrida.

P: ¿Las funciones SQL estándar de ANSI cambian los datos en la base de datos?

No. Puede usarlos para cambiar datos; por ejemplo, puedo decir:

INSERT INTO dbo.MyReport SELECT MAX(SalespersonRevenue) FROM dbo.Sales

Pero por sí mismos, solo el uso de un AVG, COUNT, MIN, MAX, etc. no debería cambiar los datos permanentemente dentro de su base de datos.

P: ¿El estándar ANSI me permite escribir mis propias funciones?

Sí, pero la implementación exacta varía de un proveedor a otro. Las funciones que escribe pueden cumplir con el estándar del lenguaje ANSI, pero lo que hace dentro de su función puede ser terriblemente horrible, como crear efectos secundarios.

• Cuando se discute el comportamiento previsto , es posible obtener una respuesta multiplataforma.
• Cuando se discuten los efectos secundarios , no lo es.

P: ¿Puedo crear mi propia función para escribir datos?

Por qué seguro, si eres creativo. Soy un chico de Microsoft SQL Server, así que me enfocaré en esa plataforma. La página de funciones de Books Online dice:

Las funciones definidas por el usuario no se pueden usar para realizar acciones que modifiquen el estado de la base de datos.

A lo que digo:

No eres mi verdadero padre.

Así que así es como rompería las reglas. Advertencia: siguen muy malas ideas.

• En su función, consulte una nueva tabla especialmente creada para este malvado propósito, y luego cree algo que vigile la tabla para ver las declaraciones seleccionadas, y luego active una acción (Eventos extendidos, auditoría o seguimiento de Profiler). Puede conectar un tipo de artilugio Rube Goldberg para realizar un trabajo basado en esas declaraciones selectas.
• En la función, llame al código CLR - diablos, incluso puede llamar a un servicio web . Ese servicio web podría muy bien enviar datos nuevamente a su propia base de datos.
• En la función, llame a xp_cmdshell y haga algo a través del símbolo del sistema. (HT @AaronBertrand en los comentarios).

Todos estos ejemplos tienen enormes inconvenientes en forma de rendimiento y consistencia transaccional. Acabas de preguntar si teóricamente podría hacerse, y la respuesta es sí. Nunca usaría ninguno de los dos en mi propio código: retrocedería y preguntaría: "¿Cuál es el objetivo comercial que estoy tratando de lograr aquí? ¿Hay alguna manera de lograrlo para lograr el rendimiento y la coherencia transaccional? ? " Si desea consejos específicos sobre eso, le haría una pregunta de Stack por separado con detalles.

Solo puedo hablar definitivamente sobre SQL Server, y parece que esto no es consistente en todas las implementaciones de bases de datos. Pero en SQL Server, las funciones pueden no producir efectos secundarios. Esta es una regla dura y rápida que he intentado eludir varias veces sin éxito.

Si está pensando en funciones en el sentido general, hay módulos SQL que permiten efectos secundarios (por ejemplo, procedimientos almacenados) pero las funciones definidas por el usuario no.

Hay un dicho "Las soluciones inteligentes no escalan" que es especialmente cierto con los productos de Microsoft. He visto una serie de soluciones ingeniosas en las primeras versiones de SQL Server que se volvieron obsoletas en versiones posteriores, porque MS las agregó como características verdaderas.

Los que nunca se convirtieron en características, sinceramente, nunca se convirtieron en características porque fundamentalmente rompieron algún aspecto del desarrollo de T-SQL. Los efectos secundarios en las funciones es uno de ellos.