From: | kernel <jucabapa(at)gmail(dot)com> |
---|---|
To: | |
Cc: | Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Problemas de tamaño/recodificacion |
Date: | 2019-08-08 17:35:16 |
Message-ID: | 1965fe32-4202-5c77-e980-4625f3e11d2c@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El 08/08/2019 a las 18:10, Alvaro Herrera escribió:
> kernel escribió:
>
>> Tengo una funcion plpgsql que me devuelve un valor xml de 0,5 GB, La
>> codificacion que tiene la DB es UTF-8, como el cliente que utilizo es
>> latin9, creo que a la hora del intercambio al hacer el cambio de encoding me
>> da el problema
> ¿para qué haces esa conversión de codificación? XML ya tiene una
> declaración de codificación en sí mismo. Es más, creo que hay algunas
> cosas en XML que no funcionan bien con codificaciones no UTF8. (Al
> menos con JSON es así).
>
> La explicación a por qué sucede que dio Horacio es correcta ... el
> código de conversión es pesimista y asume que va a necesitar mucho
> espacio (lo cual probablemente no es cierto). Quizás puedas solventar
> el problema conviertiendo por trozos, es decir divides el XML en trozos
> y conviertes cada trozo separadamente. Debe ser posible hacer esto en
> forma que sea invisible para el cliente ...
>
>
> En términos de código, esa limitación de tamaño de conversión podría
> eliminarse ahora que Postgres tiene código reciente para manejar trozos
> de memoria grandes.
Me intento explicar mejor, actualmente genero un xml desde el ERP al
que aplico una hoja de xslt y genero código tex para generar facturas en
pdf.
Ahora lo que intento es generar el xml desde la propia base de datos (no
tengo xml guardados), ahora va muchísimo mas rápido, el problema es
cuando quieres sacar muchas es cuando da el problema, ojo si tiene que
cambiar de encoding , si no se cambia no hay problema
La base de datos la tengo en UTF-8 para poder guardar cualquier
caracter, los clientes de la aplicacion son windows con encoding
windows-1252, cuando conecto ejecuto un set client_encoding = latin9.
En plpgsql le puedes hacer la declaracion inicial :
<?xml version='1.0' encoding='ISO-8859-15'?>
pero luego introducir caracteres que se introducen como resultado de
los querys son utf-8, mas lio.
Defino una variable de tipo xml y es ahí donde deposito el resultado de
la consulta y hasta ahí perfecto, el problema es al hora de retornar la
variable al cliente.
Voy a darle una vuelta haber si puedo conectar como UTF-8 y ver como se
comporta el latex a la hora de generar el PDF.
También estoy pensando en devolver xml por factura y concatenar uno
mayor en la aplicación como anterior mente habéis comentado.
Lo del parche a mi se me queda un poco grande, no tengo experiencia en
esos temas
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos T. Groero Carmona | 2019-08-08 23:27:56 | Re: Cual es el # correcto de CPU que Postgres usa |
Previous Message | Alvaro Herrera | 2019-08-08 16:27:20 | Re: PG11: particionado, parallel query y performance |