2200N

At a glance

This member covers invalid XML content. PostgreSQL 18.6’s core XML parser has a content-mode declaration guard and content-parse guards that report 2200N; the original XML option determines whether a document parse failure is instead reported as 2200M.

Meaning

This member names invalid XML content at the parser’s CONTENT boundary. In content mode, an invalid XML declaration raises invalid XML content: invalid XML declaration with a detail produced by errdetail_for_xml_code(res_code). A failed balanced-content parse raises invalid XML content; if CONTENT input contains a DOCTYPE and is parsed as a document, the failed document parse still uses the original option to select 2200N. The same failed parser call uses 2200M when the original option was DOCUMENT. The declaration branch calls errsave and the content branches call xml_errsave: with an ErrorSaveContext these errors are saved and returned to the caller, while an ordinary context throws ERROR; that distinction is separate from the dynamic DETAIL text.

Messages

The cited branches raise ERROR with primary invalid XML content: invalid XML declaration for the declaration guard, with dynamic DETAIL from errdetail_for_xml_code(res_code), or primary invalid XML content for the later content/document parse failures. The declaration variant’s evidence template is dynamic errdetail_for_xml_code(res_code), not a fixed DETAIL string. No fixed universal DETAIL or HINT should be invented for those parser failures. 2200L is the outer document-option wrapper, while 2200S and 2200T identify comment and processing-instruction syntax.

Diagnosis

Read the complete parser message and the XML fragment or value it identifies. Check element names, character data, encoding, and the operation’s expected XML level. Follow a reported 2200L, 2200M, 2200S, or 2200T directly when the server emits one of those codes; do not choose 2200N from the word “invalid” alone.

Response

Correct the XML content at the element, character, or encoding boundary named by the diagnostic, and retain the actual code when validating the fix.

When this branch raises ERROR, an explicit transaction must first be recovered with ROLLBACK or ROLLBACK TO SAVEPOINT for a savepoint established before the statement; in autocommit, retry only the corrected action after the failed statement completes. See the transaction and retry guide for this boundary rule.

Versions

The locked catalogue records this condition from 8.3.0; fixed source coverage is PostgreSQL 18.6.

Related

2200L, 2200S, 2200T

Sources

Fixed core source: src/backend/utils/adt/xml.c#L1780-1894. The shared xml_errsave/errsave helper defines the soft-error versus ordinary-throw behavior. The structured evidence record retains the declaration and content-parse guards, dynamic-detail boundary, and scope limits. Core availability depends on USE_LIBXML; no natural XML case was run for this page.