On Sun, Jun 14, 2009 at 11:28 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sat, Jun 13, 2009 at 6:40 PM, Tom Lane<tgl@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(),