Este dilema se puede tratar de diferentes formas, por lo tanto te enseñamos la respuesta más completa para nosotros.
- 8.13.1. Crear valores XML
- 8.13.2. Manejo de codificación
- 8.13.3. Acceder a valores XML
los xml
El tipo de datos se puede utilizar para almacenar datos XML. Su ventaja sobre el almacenamiento de datos XML en un text
field es que verifica que los valores de entrada estén bien formados, y hay funciones de soporte para realizar operaciones de seguridad de tipos en él; consulte la Sección 9.15. El uso de este tipo de datos requiere que la instalación se haya construido con configure --with-libxml
.
los xml
tipo puede almacenar bien formado “documentos“, según lo definido por el estándar XML, así como “contenido“ fragmentos, que se definen por referencia a los más permisivos “nodo de documento“ del modelo de datos XQuery y XPath. A grandes rasgos, esto significa que los fragmentos de contenido pueden tener más de un elemento de nivel superior o un nodo de carácter. La expresion xmlvalue IS DOCUMENT
se puede utilizar para evaluar si un xml
value es un documento completo o solo un fragmento de contenido.
Límites y notas de compatibilidad para xml
El tipo de datos se puede encontrar en la Sección D.3.
8.13.1. Crear valores XML
Para producir un valor de tipo xml
a partir de datos de caracteres, use la función xmlparse
:
XMLPARSE ( DOCUMENT value)
Ejemplos:
XMLPARSE (DOCUMENT '') XMLPARSE (CONTENT 'abc Manual ... bar foo ')
Si bien esta es la única forma de convertir cadenas de caracteres en valores XML de acuerdo con el estándar SQL, las sintaxis específicas de PostgreSQL:
xml 'bar ''bar '::xml
también puede ser usado.
los xml
type no valida los valores de entrada con una declaración de tipo de documento (DTD), incluso cuando el valor de entrada especifica una DTD. Actualmente, tampoco hay soporte integrado para la validación con otros lenguajes de esquemas XML, como XML Schema.
La operación inversa, produciendo un carácter. string valor de xml
, usa la función xmlserialize
:
XMLSERIALIZE ( DOCUMENT valueAStype)
type
puede ser character
, character varying
, o text
(o un alias para uno de esos). Nuevamente, de acuerdo con el estándar SQL, esta es la única forma de convertir entre tipos xml
y tipos de caracteres, pero PostgreSQL también le permite simplemente emitir el valor.
Cuando un personaje string el valor se envía ao desde el tipo xml
sin pasar por XMLPARSE
o XMLSERIALIZE
, respectivamente, la elección de DOCUMENT
versus CONTENT
está determinada por la “Opción XML“ parámetro de configuración de sesión, que se puede configurar mediante el comando estándar:
SET XML OPTION CONTENT ;
o la sintaxis más similar a PostgreSQL
SET xmloption TO DOCUMENT ;
El valor predeterminado es CONTENT
, por lo que se permiten todas las formas de datos XML.
8.13.2. Manejo de codificación
Se debe tener cuidado al tratar con múltiples codificaciones de caracteres en el cliente, el servidor y en los datos XML que se pasan a través de ellos. Cuando se usa el modo de texto para pasar consultas al servidor y los resultados de la consulta al cliente (que es el modo normal), PostgreSQL convierte todos los datos de caracteres pasados entre el cliente y el servidor y viceversa a la codificación de caracteres del extremo respectivo; consulte la Sección 23.3. Esto incluye string representaciones de valores XML, como en los ejemplos anteriores. Normalmente, esto significaría que las declaraciones de codificación contenidas en datos XML pueden volverse inválidas ya que los datos de caracteres se convierten a otras codificaciones mientras viajan entre el cliente y el servidor, porque la declaración de codificación incrustada no cambia. Para hacer frente a este comportamiento, las declaraciones de codificación contenidas en cadenas de caracteres presentadas para la entrada al xml
tipo son ignorado, y se supone que el contenido está en la codificación del servidor actual. En consecuencia, para un procesamiento correcto, las cadenas de caracteres de los datos XML deben enviarse desde el cliente en la codificación de cliente actual. Es responsabilidad del cliente convertir los documentos a la codificación actual del cliente antes de enviarlos al servidor o ajustar la codificación del cliente de forma adecuada. En la salida, valores de tipo xml
no tendrá una declaración de codificación y los clientes deben asumir que todos los datos están en la codificación actual del cliente.
Cuando se usa el modo binario para pasar los parámetros de consulta al servidor y los resultados de la consulta al cliente, no se realiza ninguna conversión de codificación, por lo que la situación es diferente. En este caso, se observará una declaración de codificación en los datos XML, y si está ausente, se asumirá que los datos están en UTF-8 (como lo requiere el estándar XML; tenga en cuenta que PostgreSQL no es compatible con UTF-16) . En la salida, los datos tendrán una declaración de codificación que especifica la codificación del cliente, a menos que la codificación del cliente sea UTF-8, en cuyo caso se omitirá.
No hace falta decir que el procesamiento de datos XML con PostgreSQL será menos propenso a errores y más eficiente si la codificación de datos XML, la codificación del cliente y la codificación del servidor son las mismas. Dado que los datos XML se procesan internamente en UTF-8, los cálculos serán más eficientes si la codificación del servidor también es UTF-8.
Precaución
Es posible que algunas funciones relacionadas con XML no funcionen en absoluto con datos que no son ASCII cuando la codificación del servidor no es UTF-8. Se sabe que esto es un problema para
xmltable()
yxpath()
en particular.
8.13.3. Acceder a valores XML
los xml
El tipo de datos es inusual porque no proporciona ningún operador de comparación. Esto se debe a que no existe un algoritmo de comparación bien definido y universalmente útil para datos XML. Una consecuencia de esto es que no puede recuperar filas comparando un xml
columna contra un valor de búsqueda. Por lo tanto, los valores XML deben ir acompañados de un key campo como un ID. Una solución alternativa para comparar valores XML es convertirlos primero en cadenas de caracteres, pero tenga en cuenta que el carácter string la comparación tiene poco que ver con un método de comparación XML útil.
Dado que no hay operadores de comparación para el xml
tipo de datos, no es posible crear un índice directamente en una columna de este tipo. Si se desean búsquedas rápidas en datos XML, las posibles soluciones incluyen convertir la expresión a un carácter string escribir e indexar eso, o indexar una expresión XPath. Por supuesto, la consulta real tendría que ajustarse para buscar por la expresión indexada.
La funcionalidad de búsqueda de texto en PostgreSQL también se puede utilizar para acelerar las búsquedas de documentos completos de datos XML. Sin embargo, el soporte de preprocesamiento necesario aún no está disponible en la distribución de PostgreSQL.
Anterior | Hasta | próximo |
8.12. Tipo de UUID | Hogar | 8.14. Tipos JSON |
Aquí tienes las comentarios y puntuaciones
Agradecemos que quieras proteger nuestra tarea dejando un comentario y dejando una puntuación te damos las gracias.