Ah, yo creía que directamente el driver JDBC para postgres no soportaba múltiples sentencias (se ve que existe esta limitación pero solo para ciertas tipos de ejecuciones; en particular para obtener datos basados en “cursores” http://jdbc.postgresql.org/documentation/83/query.html#query-with-cursor , pero no es el caso… creo).
Ahora me puse a mirar un poco el código de la clase CPreparedStatement que usa PluginXMLUpdater para llevar a cabo el preinstall, y veo, si no me equivoco, que en al fin y al cabo cuando uno ejecuta el executeUpdate sobre esta clase, esto termina llevando a cabo un executeUpdate sobre un objeto de la subclase especifica del driver de Postgres para la clase JDBC PreparedStatement. El tema es que los PreparedStatement son objetos en el “servidor” y son preprocesados (la idea si no entendí mal es que se suponen que van a ser llamados mas de una vez, y este preprocesamiento evita el “replaneamiento” y “recompilación” de la sentencia Sql a nivel de postgres y otras mejoras a nivel de performance; en este caso NO lo veo para nada necesario, ya que el preinstall no es una “sentencia” que se va ejecutar mas de una vez). Me pregunto si todo estos problemas no surgen porque se esta usando un PreparedStatement en vez de usar simplemente un Statement (este no es preprocesado). Tal vez usando esta clase en estos casos particulares se solucione no solo el tema de los comentarios si no también el tema de las referencias. Voy a intentar testearlo (si ya lo probaron y no anduvo avísenme así me ahorro el trabajo).[la clase CStatement debe hacer esto]
PD : creo que Libertya usa PreparedStatement siempre… me pregunto si este uso es correcto, ya que la idea del usar estos es repetir la misma sentencia solo variando los parámetros (supongo que a nivel de conexión de red JDBC envia primero la sentencias, y después por cada ejecución solo envia los parámetros; de ahi una mejora en performance, PERO SOLO cuando la sentencia ser repite muchas veces). Digamos, al cargar la ventana Productos, el select que los trae, no tiene sentido que sea un PreparedStatement (no tiene ninguna mejora sobre el Statement simple y ademas debe generar un overhead innecesario).
PD 2: bueno, PreparedStatement nivel de API tiene la capacidad de setear parámetros via setXXXs, lo cual lo hace muy util a nivel de programación y esto es usado asiduamente en Libertya; Statement no tiene esta funcionalidad (no entiendo bien por qué pero bueno…). E.d Statement en vez de PreparedStatement puede ser lo más correcto desde el punto de vista de base de datos, pero a nivel de programación complica mucho las cosas.
