Recently I needed to create XML straight from a relational database. The use case was to create an import file for Wordpress (WRX) without writing any line of Python or Ruby code. The legacy blogging application was using a PostgreSQL database that holds: users/authors, articles, comments and some other relations.

It's not the intention to describe the whole process here. Much more, it attempts to make it adaptable to other situations.

Importing users/authors (no aggregation)

The easiest case was the users table without any relations and no need for aggregation. The goal was to create XML elements like this:


This can be done with this select statement:

SELECT xmlelement(
    name "wp:author",
        xmlforest (
          id as "wp:author_id",
          username as "wp:author_login",
          email as "wp:author_email",
          first_name as "wp:display_name",
          first_name as "wp:first_name",
          last_name as "wp:last_name"
FROM users ORDER BY id;

The xmlelement expression produces an XML element with the name wp:author. Then instead of nesting six other xmlelement statements (for id, username, ...), it was easier (and even more readable) to make use of the xmlforest expression and create a sequence of the given elements.

Articles and comments (covering XML aggregation)

The goal was to create XML elements like this. An item can have none or multiple comments:

  <title>PostgreSQL rocks!</title>
  <!-- ... -->
  <!-- first comment -->
    <!-- ... -->
    <wp:comment_content>I like it!</wp:comment_content>
  <!-- next comment -->
    <!-- ... -->

It is necessary to use a LEFT JOIN on comments and GROUP BY (ID of the article) to also include articles without comments. To make it clear - the second column (count) of the following select statement can be zero:

FROM posts p
  LEFT JOIN comments c ON c.post_id =

Basically, the first part of the final statement is identical to the first example. The xmlelement expression creates the item node and the xmlforest expression creates it's children.

The xmlagg expression expects an XML element at the first argument. It just concatenates the elements created by the xmlelement expression and passes it to the aggregation call.

SELECT xmlelement(
    name item,
        xmlforest (
            p.title as "title",
            '' || to_char(date, 'YYYY') || '/' || to_char(date, 'MM') || '/' || to_char(date, 'DD') || '/' || p.slug as "link",
   as "pubDate",
            (SELECT username FROM users u WHERE = p.author_id) as "dc:creator",
            '' ||  as "guid",
            '' as "description",
            p.body as "content:encoded",
            p.excerpt as "excerpt:encoded",
   as "wp:post_id",
            -- ... skipped
            date as "wp:post_date"
                name "wp:comment",
           as "wp:comment_id",
                    c.user_name as "wp:comment_author",
                    c.user_email as "wp:comment_author_email",
                    -- skipped ...
                    c.comment as "wp:comment_content",
           / as "wp:comment_approved" -- '1'
FROM posts p
  LEFT JOIN comments c ON c.post_id =

I had some unexpected results when using constants like '1' or '0' within the xmlagg functions. The following node was generated, even if an article does not have any comments.


The solution was to express '0' and '1' by using the comment's ID: - as "wp:comment_parent" -- '0' / as "wp:comment_approved" -- '1'

Further information

For additional information on PostgreSQL's XML functions, check out this section of the manual.