On Sun, Jun 14, 2009 at 11:28 AM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sat, Jun 13, 2009 at 6:40 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: >>> I believe we have things set up so that you can still print "xml" data >>> without libxml configured in. We'd need to be sure casting to text >>> works too, but other than that I don't see an issue here. > >> Hmm, I just tried to do this by modifying ExplainResultDesc to use >> XMLOID rather than TEXTOID when stmt->format == EXPLAIN_FORMAT_XML, >> and sure enough, explain (format xml) ... fails when --with-libxml is >> not specified. > > That's because the code goes through BuildTupleFromCStrings, which > invokes xml_in in this scenario, and xml_in (as opposed to xml_out) > does depend on libxml. > > However, using BuildTupleFromCStrings is wasteful/stupid for *both* > text and xml output, so it seems like getting rid of it is the thing > to do here.
Makes sense. However, if we just make that change in do_tup_output(), then we'll break the ability to use that function for non-text datatypes. Currently that doesn't look like a problem, because the only clients are ShowGUCConfigOption(), do_text_output_oneline(), and do_text_output_multiline(), -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
