DEV Community: Sergio Majé

Processing XML in PostgreSQL: Do You Really Need PL/Python?

Sergio Majé — Thu, 15 Oct 2026 17:07:51 +0000

In my previous article, I explained how a university assignment led me to run Python inside PostgreSQL to validate XML documents against an XSD.

It worked. I completed the assignment, learned something new about PostgreSQL, and moved on.

Two years later, I revisited the project with a different question in mind: how much of that solution actually needed Python?

PostgreSQL already provides functions for generating XML, querying its contents, and extracting values into relational columns. What it doesn't provide natively is validation against an arbitrary XML Schema Definition (XSD).

But while reviewing the original files, I found something I hadn't fully appreciated at the time.

Some XML documents produced by the SQL query didn't satisfy the very XSD they were supposed to follow.

That turned a simple comparison of database features into a more interesting engineering question. Before deciding where XML validation should happen, we need to know whether the document and its schema agree on what valid data looks like.

Let's explore what PostgreSQL can do on its own, what PL/Python added to the original solution, and how I would approach the same decision today.

One assignment, two different problems

Looking back at the assignment, I realized I'd been treating "XML processing" as a single requirement.

It was actually two separate workflows.

The first started with relational data. I needed to query employee records, including their job history, and generate an XML document from the results.

The second worked in the opposite direction. I needed to receive an XML document, validate it against an XSD, extract its values, and insert them into relational tables.

Here's the difference:

GENERATING XML

Relational tables
       |
       v
      SQL
       |
       v
  XML document


RECEIVING XML

  XML document
       |
       v
 XSD validation
       |
       v
  SQL extraction
       |
       v
Relational tables

Both workflows involve XML, but that doesn't mean they require the same tools.

Generating a document is about transforming relational data into an XML structure. Receiving a document may introduce an additional requirement: proving that the document follows a defined schema.

That distinction matters because parsing XML and validating an XML contract are different operations.

PostgreSQL handles much of the first workflow, and part of the second, without needing Python at all.

The unexpected problem in my original assignment

Before getting into the PostgreSQL features, there's a discovery worth discussing.

One of my original SQL queries generated an XML document containing employee details and job history records.

An employee could have no previous jobs, one previous job, or several. The relational data model naturally allowed those possibilities.

The XML Schema, however, didn't account for all of them.

It defined an optional jobHistories container, but once that container appeared, the schema expected exactly one jobHistory element.

Why exactly one?

Because the nested jobHistory declaration didn't specify minOccurs or maxOccurs. In XSD, both default to 1.

That became a problem when I recreated the query using three synthetic employees.

One had no job history, another had one record, and the third had two.

I generated the XML and checked each document against the unchanged historical XSD.

Here's what happened:

Job history records	Generated XML	XSD result
0	An empty `<jobHistory/>` element	Invalid
1	One populated `<jobHistory>`	Valid
2	Two `<jobHistory>` elements	Invalid

The first failure happened because the query generated an empty jobHistory element. The schema required that element to contain fields such as startDate.

The third failed for a different reason. The XML contained two job history records, but the XSD allowed only one.

And this is the important part: none of those failures meant PostgreSQL had generated malformed XML.

The documents were well-formed. They simply didn't satisfy the contract defined by the schema.

That raises a question the validator cannot answer for us.

Should the schema allow multiple job history records? Or was the query supposed to return only one?

If an employee has no job history, should the document omit the optional container instead of generating an empty record?

Those are questions about requirements and data modeling, not about which XML parser to use.

A validator can tell us when two components disagree. It can't decide which one represents the correct business requirement.

For me, that was the most useful discovery in the retrospective. Before worrying about whether to use PostgreSQL, Python, or something else for validation, I needed to make sure the XML and XSD described the same contract.

The three cases are reproduced in 04-historical-output-xsd-cases.sql.

What PostgreSQL can already do with XML

Now let's look at the operations that don't require Python.

PostgreSQL supports a collection of SQL/XML features for working with XML data directly in SQL.

Rather than listing every function, I'll focus on the ones that mattered for the assignment.

Generating XML from relational data

Suppose we want to generate an XML document containing an employee's name and salary.

We can do that with SQL alone:

SELECT XMLELEMENT(
    NAME employee,
    XMLFOREST(
        'Ada'::text AS "firstName",
        1200.50::numeric AS salary
    )
) AS document;

The resulting XML is equivalent to:

<employee>
  <firstName>Ada</firstName>
  <salary>1200.50</salary>
</employee>

Two functions do the work here.

XMLELEMENT creates an XML element, while XMLFOREST turns SQL expressions into child elements.

For more complex documents, PostgreSQL also provides XMLATTRIBUTES and XMLAGG.

XMLATTRIBUTES lets us add attributes to an element. XMLAGG combines XML values from multiple rows, which is particularly useful when dealing with relationships such as an employee's job history.

In the reconstructed experiment, I used these features to generate documents from employees with zero, one, and multiple job history records.

The example also checks ordering, omitted null fields, and the expected output structure.

You can find it in 01-native-xml-generation.sql.

One detail is worth clarifying: the XML generation itself uses native PostgreSQL functions and doesn't require PL/Python. The reproducible test script also validates the generated document against an example XSD, and that additional validation step does use lxml through PL/Python.

In other words, PostgreSQL builds the document. Python checks whether it follows the chosen schema.

Extracting XML into relational columns

The reverse operation is also supported natively.

Let's say an application sends us this document:

<employee>
  <firstName>Ada</firstName>
  <salary>1200.50</salary>
</employee>

We can turn those values into SQL columns using XMLTABLE:

SELECT employee.first_name, employee.salary
FROM XMLTABLE(
    '/employee'
    PASSING XMLPARSE(
        DOCUMENT
        '<employee>
           <firstName>Ada</firstName>
           <salary>1200.50</salary>
         </employee>'
    )
    COLUMNS
        first_name text PATH 'firstName',
        salary numeric PATH 'salary'
) AS employee;

The result looks like any other SQL query:

first_name	salary
Ada	1200.50

XMLPARSE interprets the XML document. XMLTABLE then uses XPath expressions to locate the elements and convert their values into the SQL types we've specified.

We haven't written any Python code.

For extracting known values into relational columns, that's often all we need.

There's more than XMLTABLE

PostgreSQL also provides xpath(), xpath_exists(), and XMLEXISTS for querying XML documents.

Namespaces require some care, though.

In one of my tests, a document used a default XML namespace. A simple XPath expression such as /employee returned no rows because it didn't match the namespace-qualified element.

Declaring an explicit namespace alias through XMLNAMESPACES and then using /e:employee solved the problem.

There's also a limitation worth remembering: PostgreSQL 18's XML querying features rely on XPath 1.0. They aren't a complete XQuery implementation.

Still, these functions cover the generation and extraction operations I needed to demonstrate.

So where does that leave PL/Python?

What PL/Python actually contributed

The first article covered the implementation in detail, so I won't repeat the full validator here.

The key idea was to use PostgreSQL's plpython3u extension to execute Python and its lxml library inside the database server.

That allowed me to validate an incoming XML document against an XSD before extracting and inserting its values.

Looking at the solution today, I can draw a much clearer boundary around what Python was doing.

I didn't need it to build XML elements, execute XPath queries, convert a salary into a numeric column, or insert a row.

I needed it because the assignment required XSD validation inside PostgreSQL.

Those aren't interchangeable capabilities.

PostgreSQL can recognize well-formed XML and perform conversions to SQL types. But that doesn't mean it has verified every rule in an XML schema.

An XSD can define required elements, element ordering, occurrence limits, and accepted data types. PostgreSQL 18 doesn't provide built-in validation of arbitrary documents against those schemas.

PL/Python gave me a way to fill that gap.

It also introduced a different set of responsibilities.

The plpython3u language is untrusted. Python code runs within the PostgreSQL server's process, and creating functions in that language requires superuser privileges.

Deploying this approach means dealing with Python dependencies, function ownership, access permissions, parser behavior, and database-server maintenance.

The reconstructed experiment includes parser restrictions and tests for malformed or potentially problematic inputs. Those checks help make the experiment more controlled, but they don't turn it into a production-ready security design.

For my university assignment, the trade-off was understandable. Keeping the validation inside PostgreSQL was part of the constraint I was trying to satisfy.

In a real application, though, I'd first ask whether the database server was the right place for that responsibility.

What if validation happened in the application?

Here's another approach.

Suppose XML documents arrive through an API or an integration service. That component already has to receive the input, identify the request, and decide how to handle failures.

Instead of sending the XML to PostgreSQL for schema validation, the application could validate it first using an XSD-capable library.

The flow would look like this:

 Incoming XML
      |
      v
 API / Ingestion service
      |
      v
   XSD validation
      |
   Valid?
   /    \
  No    Yes
  |      |
Reject  Extract data
           |
           v
       PostgreSQL

This keeps the XML validation dependencies outside the database server and places input validation closer to the point where the document enters the system.

It also lets PostgreSQL focus on storing and protecting the resulting data.

At first glance, that separation is attractive.

But there's a catch.

Application-side validation only enforces the contract if every relevant write path goes through it.

Imagine that an API checks every incoming XML document, but a batch-processing job can write directly to the same tables.

That job might bypass the validation entirely.

The system therefore needs a clear answer to questions such as who can write to the database, which operations are permitted, and what invariants PostgreSQL must enforce independently.

Moving validation out of the database doesn't remove the need for a trustworthy persistence boundary.

It changes where the responsibility lives.

I haven't implemented or benchmarked an equivalent application-side validator as part of this experiment. So I can't honestly say that it would be faster, more secure, or easier to operate for this particular workload.

Those outcomes would depend on the application's architecture, deployment environment, and security requirements.

Still, it's an alternative I would definitely evaluate before choosing an in-database Python implementation.

So, when would I use PL/Python?

After reviewing the project, I'd start with the actual requirement rather than the available extensions.

Here's how I'd approach the different XML-related tasks:

Requirement	Where I'd start
Generate XML from relational rows	PostgreSQL's native SQL/XML functions
Extract known fields from XML	`XMLTABLE` or XPath
Validate an XSD inside PostgreSQL	Evaluate PL/Python with an XSD-capable library
Validate external XML before persistence	An ingestion service or application, with controlled database writes

These aren't universal rules. They're starting points for evaluating a design.

If the task is simply to generate an XML document from existing tables, I'd use the native SQL/XML features first.

If I need to extract a handful of known values from XML, XMLTABLE is a natural option to investigate.

If schema validation must happen inside PostgreSQL, PL/Python becomes a possible solution, but one that needs deliberate consideration of its operational and security implications.

And if I control the application receiving the XML, I'd examine whether that is the more appropriate validation boundary.

Before making any of those choices, however, I'd verify that the schema actually represents the expected document.

The job history mismatch taught me why that step shouldn't be taken for granted.

Choosing a validator won't fix an incorrect contract.

Looking back, what would I do differently?

When I originally developed the assignment, my goal was fairly narrow: validate XML against an XSD while staying with PostgreSQL.

I found a way to do that, and it was a worthwhile technical exercise. It introduced me to PL/Python and encouraged me to explore capabilities I hadn't previously used.

But revisiting the project changed what I consider the most interesting part of the problem.

Today, I wouldn't begin by asking how to run Python in PostgreSQL.

I'd ask what the system needs to guarantee, which component owns that guarantee, and whether the XML schema correctly describes the data we expect to exchange.

Only then would I choose the tools.

The historical mismatch between the generated documents and their XSD makes that lesson particularly clear. The SQL could produce well-formed XML, and the validator could correctly reject it, while the underlying disagreement about the data contract remained unresolved.

That's the difference between making a technical solution work and understanding whether the system is doing the right thing.

PL/Python solved a specific limitation in my original assignment. I wouldn't rule it out today, but I wouldn't reach for it automatically either.

The real engineering decision isn't whether PostgreSQL can execute Python. It's whether executing Python inside PostgreSQL is the right way to meet the system's requirements.

And sometimes, the most useful thing about revisiting an old solution isn't finding a better implementation. It's learning to ask a better question.

Source code and references

The reproducible examples are available in smaje99/postgresql-xml-plpython, published under the GPL-3.0-only license.

The recorded experiments use PostgreSQL 18.6.

Version note: As of October 15, 2026, PostgreSQL 19 RC 1 was available. Its development documentation still did not describe built-in XSD validation. I haven't tested these examples on PostgreSQL 19; the experimental results discussed here come from PostgreSQL 18.6. PostgreSQL 19 remains a prerelease, so this observation is provisional.

This article presents a retrospective analysis of an educational experiment, not a universal production architecture recommendation.

Why I Ended Up Running Python Inside PostgreSQL to Validate XML

Sergio Majé — Tue, 13 Oct 2026 03:31:23 +0000

Two years ago, a university database assignment led me to do something I hadn't expected: run Python code inside PostgreSQL.

The assignment was straightforward on paper. I needed to accept an XML document, validate it against an XSD schema, and insert the data into relational tables.

I had chosen PostgreSQL for the project. I was already familiar with some of its capabilities, and I wanted to use the assignment to explore the database further.

Things got interesting when I was halfway through the implementation.

PostgreSQL could parse XML, extract values, and turn them into relational data. What I couldn't find was a built-in way to validate a document against an XML Schema Definition (XSD).

Oracle XML DB supported that kind of validation, so switching databases was an option. But I had already invested time in PostgreSQL, and I was curious about whether I could make it work.

That's how I discovered PL/Python.

In this article, I'll walk through the problem, show how I combined PostgreSQL with Python's lxml library, and explain what I learned when I revisited the solution two years later.

This is a practical experiment rather than a recommendation to move XML validation into every database.

The problem: reading XML wasn't enough

Let's start with a simple example.

Suppose an application receives employee records as XML documents. Each document contains information that eventually needs to be stored in a database.

Here's one of our sample records:

<employee>
  <firstName>Ada</firstName>
  <salary>1200.50</salary>
  <hireDate>2024-01-31</hireDate>
</employee>

Nothing particularly complicated here. We have a name, a salary, and a hiring date.

PostgreSQL provides tools for extracting these values, so getting them into relational columns isn't especially difficult.

But receiving a document doesn't mean we should trust its contents.

What if the salary looked like this?

<salary>quite a lot</salary>

As far as XML syntax is concerned, there's nothing wrong with that element. The opening and closing tags match, and the content is valid text.

Our application, however, expects a number.

This is where an XSD comes in.

An XML Schema Definition describes what a document is supposed to look like. It can define required elements, their order, accepted data types, and optional fields.

For our employee document, the rules might say that firstName must be a string, salary must be a decimal, and hireDate must be a date.

Those rules introduce an important distinction:

A document can be well-formed XML without being valid according to an XSD.

That difference was at the heart of my assignment.

Where PostgreSQL stopped short

PostgreSQL has supported XML operations for years.

It includes an xml data type and functions such as XMLPARSE, xpath(), and XMLTABLE. These are useful when you need to inspect XML documents or work with their contents in SQL.

For instance, consider this query:

SELECT xml_is_well_formed_document(
  '<employee>
     <firstName>Ada</firstName>
     <salary>quite a lot</salary>
     <hireDate>2024-01-31</hireDate>
   </employee>'
);

PostgreSQL returns true.

And that's correct. The document is well-formed XML.

The problem is that a successful syntax check tells us nothing about whether quite a lot is an acceptable salary under our schema.

PostgreSQL 18's documentation makes the limitation clear: while the database can parse and process XML, it doesn't provide built-in validation against XML Schema.

I could extract the values and rely on SQL types and constraints to catch certain problems. But that wouldn't be the same as validating the entire document against the rules defined in an XSD.

I needed to add a missing capability without replacing everything PostgreSQL already handled well.

Enter PL/Python

One feature I particularly like about PostgreSQL is its support for procedural languages.

Besides SQL and PL/pgSQL, PostgreSQL can run functions written in other languages, including Python.

The relevant extension is called plpython3u.

Once the appropriate server-side package is installed, the language can be enabled in a database using:

CREATE EXTENSION plpython3u;

This allows a PostgreSQL function to execute Python code inside the database server's process.

That last part matters.

I wasn't trying to build a separate Python service that would communicate with PostgreSQL. The assignment kept the validation logic inside the database, so I needed Python to run there.

The other half of the solution was lxml, a Python library with support for XML Schema validation.

With those two pieces, I could keep the workflow simple:

Incoming XML + XSD
        |
        v
 PL/Python + lxml
        |
   XSD validation
      /     \
    Fail    Pass
     |        |
   Reject  XMLTABLE
              |
              v
          SQL columns
              |
              v
            INSERT

Python would check the document against the schema. PostgreSQL would handle the relational side.

That division of responsibilities gave me what I needed for the assignment without attempting to reimplement PostgreSQL's existing XML features.

Building the XSD validation step

Before looking at the Python code, let's define the rules for our sample employee.

A minimal XSD could look like this:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="employee">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="firstName" type="xs:string"/>
        <xs:element name="salary" type="xs:decimal"/>
        <xs:element name="hireDate" type="xs:date"/>
        <xs:element name="nickname"
                    type="xs:string"
                    minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

If you haven't worked much with XSD, focus on two attributes.

The type attribute defines the kind of value each element accepts. And minOccurs="0" makes the nickname element optional.

The xs:sequence declaration also specifies the order in which those elements should appear.

Now we need Python to interpret these rules and check an incoming XML document.

The core validation logic is surprisingly small:

from lxml import etree

# Parse the XSD and build a validator.
xsd_root = etree.fromstring(xsd_bytes, parser())
schema = etree.XMLSchema(xsd_root)

# Parse the incoming XML document.
xml_root = etree.fromstring(xml_bytes, parser())

# Validate the document against the schema.
is_valid = schema.validate(xml_root)

This is a simplified excerpt, not a complete standalone function. The actual implementation includes parser configuration, error handling, and input checks.

The important part is how etree.XMLSchema and schema.validate() work together.

First, lxml parses the schema. Then it compiles the schema into a validator. Finally, the validator checks whether the document follows its rules.

If we provide 1200.50 as the salary, the document passes that type check. If we use quite a lot, it fails because the value doesn't match xs:decimal.

And unlike PostgreSQL's well-formedness check, this validation can also detect missing required elements, unexpected elements, and other violations of the schema.

Returning useful errors

My original university implementation raised a PostgreSQL error whenever XSD validation failed.

That worked for rejecting the document, but it wasn't particularly useful for understanding different failure scenarios.

When I reconstructed the experiment, I changed the helper to return structured JSON results.

Instead of exposing only a boolean, the result identifies whether the failure happened while parsing the XML, preparing the XSD, or validating the document against it.

For example, a schema-validation failure can produce a result with the following fields:

{
  "valid": false,
  "stage": "xsd_validation",
  "category": "xsd_invalid"
}

The helper also includes diagnostic details when available.

This makes it easier for the SQL layer to handle a rejected document consistently.

You can inspect the complete implementation in 03-xsd-validation-cases.sql.

Turning validated XML into SQL rows

Once the XML passes validation, we still need to store its data.

I could have written that part in Python too, but PostgreSQL already has a suitable tool: XMLTABLE.

It lets us read values from an XML document and present them as columns in a SQL query.

Here's a small example:

SELECT *
FROM XMLTABLE(
    '/employee'
    PASSING XMLPARSE(
        DOCUMENT '<employee>
                    <firstName>Ada</firstName>
                    <salary>1200.50</salary>
                    <hireDate>2024-01-31</hireDate>
                  </employee>'
    )
    COLUMNS
        first_name text PATH 'firstName',
        salary numeric PATH 'salary',
        hire_date date PATH 'hireDate'
) AS employee;

The query produces a relational row with a name, a numeric salary, and a date.

XMLTABLE does more than select text from the document. It also converts values into the SQL types we specify.

Still, successful SQL type conversion doesn't mean an XML document satisfies its XSD. The schema may impose additional requirements that cannot be inferred from these three columns alone.

That's why I kept schema validation and relational extraction as separate steps.

In the reproducible implementation, a PL/pgSQL function calls the Python validator first:

validation_result :=
    xml_research.validate_xml_xsd_case(
        xml_text, xsd_text
    );

IF COALESCE(
    (validation_result->>'valid')::boolean,
    false
) IS NOT TRUE THEN
    RAISE EXCEPTION USING
        ERRCODE = '22023',
        MESSAGE = format(
            'XML rejected during %s: %s',
            validation_result->>'stage',
            validation_result->>'category'
        );
END IF;

This excerpt runs inside a PL/pgSQL function.

If validation fails, the function raises an exception before reaching the INSERT. I chose SQLSTATE 22023 as the error code for these rejections in the experiment.

If validation succeeds, the function uses XMLTABLE to extract the values and insert them into a temporary relational table.

The result is a small processing pipeline in which Python validates the XML contract and PostgreSQL handles the database operations.

Revisiting the implementation two years later

The original assignment was built on PostgreSQL 15.

For this article, I wanted something more useful than a description of an old university project. So I revisited the implementation and created a reproducible experiment using PostgreSQL 18.6.

The repository is available here:

smaje99/postgresql-xml-plpython

It includes the Docker configuration, SQL scripts, synthetic XML fixtures, and validation tests.

You can run the examples locally without configuring PostgreSQL and PL/Python manually on your machine.

Running the experiment

You'll need Docker Engine with the Compose plugin, plus Python 3 to generate a local password.

Start by cloning the repository:

git clone https://github.com/smaje99/postgresql-xml-plpython.git
cd postgresql-xml-plpython
cp .env.example .env

Generate a password:

python3 -c 'import secrets; print(secrets.token_urlsafe(32))'

Add the generated value to .env as POSTGRES_PASSWORD, then start the database:

docker compose up --build -d
docker compose ps

To run the validation and insertion tests:

docker compose run --rm --no-deps postgres sh -c \
'PGPASSWORD="$POSTGRES_PASSWORD" psql \
-v ON_ERROR_STOP=1 \
-h postgres \
-U "$POSTGRES_USER" \
-d "$POSTGRES_DB" \
-f /workspace/sql/03-xsd-validation-cases.sql'

The script checks its own expected outcomes and raises an error if a test fails.

The repository's README also covers the other XML experiments, including generating XML from relational tables. That was another part of the original assignment, but the focus here is validating incoming documents before storing their data.

When you're done, use docker compose stop to stop the database while keeping its data volume. The README also explains how to remove the disposable environment.

What the tests showed

The updated experiment includes 17 validation cases.

They cover more than just valid and invalid salaries. I also tested missing required elements, invalid dates, malformed XML, malformed XSD, unexpected elements, and namespace mismatches.

Other cases examine how the parser handles DTD declarations, entities, external schema references, oversized inputs, and deeply nested documents.

In the recorded PostgreSQL 18.6 environment, all 17 cases matched their expected results.

The persistence tests inserted two valid employee documents: one with only the required fields and another with an optional nickname.

The temporary table ended up containing:

first_name | salary  | hire_date  | nickname
-----------+---------+------------+----------
Ada        | 1200.50 | 2024-01-31 | NULL
Ada        | 1200.50 | 2024-01-31 | Countess

The remaining 15 cases were rejected with SQLSTATE 22023, and the tests verified that they added no rows.

Revisiting the old implementation also exposed a small issue in its error handling.

The historical function called plpy.error() when a document failed validation, followed by a return False. But plpy.error() raises an exception, so execution never reaches that return statement.

In the newer experiment, the Python helper returns structured validation information, and the PL/pgSQL wrapper decides whether to raise a SQL exception.

It's a clearer separation, and it makes the behavior easier to test.

But passing a test suite doesn't automatically make the solution production-ready.

What I would worry about in a real system

The biggest consideration is PL/Python itself.

The u in plpython3u stands for untrusted. PostgreSQL does not sandbox this language as a trusted procedural language, and only superusers can create functions written in it.

Running Python inside the database server is powerful, but it also introduces security and operational responsibilities.

You need to think about who owns the functions, who can execute them, which permissions they have, and what happens when a dependency or runtime needs updating.

XML parsing deserves particular care as well.

In the reproducible experiment, the lxml parser is configured to disable entity resolution, DTD loading, network access, and huge-tree mode. The helper rejects external schema directives and enforces explicit limits on input size and nesting depth.

Those restrictions are part of the laboratory's test policy. They shouldn't be treated as universally safe settings or a substitute for a full security review.

There's another architectural question: who gets to decide which XSD is trusted?

In this experiment, both the XML and the XSD are passed to the function. The parser restrictions address certain technical risks, but they don't establish ownership, approval, or versioning rules for schemas.

A real application would need to deal with that separately.

Performance is also an open question. The helper compiles the schema during validation and performs additional parsing checks. I haven't benchmarked the implementation under load, so I can't claim that it scales efficiently or outperforms application-side validation.

The recorded environment used PostgreSQL 18.6, Python 3.11.2, lxml 4.9.2.0, and libxml2 2.9.14. I haven't tested this implementation across every PostgreSQL release or verified its deployment on managed PostgreSQL services.

These limitations don't invalidate the experiment. They define what it actually demonstrates.

Would I still choose PL/Python today?

I enjoyed working on this solution because it pushed me to explore PostgreSQL beyond the features I already knew.

For the original assignment, it made sense. I needed to keep the validation workflow inside the database, and PL/Python let me add XSD validation while continuing to use PostgreSQL's SQL/XML features.

But if I were designing a production system that receives XML from external users or services today, I wouldn't automatically put the validator inside PostgreSQL.

I'd first look at the application's boundaries.

Where should a document be accepted or rejected? Who owns the schema? How should validation errors reach the client? And what would placing Python inside the database mean for deployment, security, and maintenance?

Validating XML in the application before it reaches the database is another reasonable option. Whether that approach is preferable depends on the system's requirements and constraints.

That's the question I want to explore in the follow-up article: Do we really need PL/Python to process XML in PostgreSQL?

For now, this experiment taught me something valuable.

Knowing that a database can do something is useful. Understanding when it should do it is an entirely different engineering decision.

And sometimes, exploring a limitation is what helps you understand a tool better.

Source code and further reading

The reproducible experiment is published under the GPL-3.0-only license.

This is an educational experiment, not a production-ready XML validation service.