Skip site navigation (1) Skip section navigation (2)

Re: FDW API: don't like the EXPLAIN mechanism

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: FDW API: don't like the EXPLAIN mechanism
Date: 2011-02-21 17:12:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On 02/21/2011 11:45 AM, Mark Mielke wrote:
> On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
>> On 02/21/2011 11:23 AM, Tom Lane wrote:
>>> Andrew Dunstan<andrew(at)dunslane(dot)net>  writes:
>>>> If we allow the invention of new explain states we'll never be able to
>>>> publish an authoritative schema definition of the data. That's not
>>>> necessarily an argument against doing it, just something to be 
>>>> aware of.
>>>> Maybe we don't care about having EXPLAIN XML output validated.
>>> I thought one of the principal arguments for outputting XML/etc formats
>>> was exactly that we'd be able to add fields without breaking readers.
>>> If that's not the case, why did we bother?
>> Well, I thought the motivation was to allow easy construction of 
>> parsers for the data, since creating a parser for those formats is 
>> pretty trivial.
>> Anyway, if we don't care about validation that's fine. I just didn't 
>> want us to make that decision unconsciously.
> Parsing XML isn't trivial, not if done correctly... :-)
> I don't see the benefit of validation beyond test suites, and then the 
> specification can be published with the version of PostgreSQL (as 
> XSD?) if so necessary.
> Primary benefits include:
> 1) Open and widely recognized format.
> 2) Well tested and readily available parsers already exist.
> 3) Able to easily add content without breaking existing parsers or 
> analyzers, provided the parsers and analyzers are written properly.
> Any XML parser that does:  m[<tag>(.*?)</tag>]  ... is not written 
> properly.

Parsing all these formats is trivial enough if you use a library to do 
the heavy lifting for you. I do *lots* of XML/XSL work and I don't use 
stuff like "m[<tag>(.*?)</tag>]".  Here's a fragment from a working 
program written a week or two back in perl:

    my $parser= XML::DOM::Parser->new();
    my $xp = $parser->parsefile($xmlfile);
    my ($provider) = $xp->findvalue("//SERVICE_PROVIDER_CODE");
    my ($invoice_num) = $xp->findvalue("//invoice_num");

Not that hard, is it? No regex matching there. :-)

Regarding your other suggestion, the whole point I have been making is 
that if external modules can invent arbitrary nodes then we can't 
publish an XSD (or RelaxNG or DTD) spec that is worth anything at all.

Anyway, it seems like that's what people want.



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-21 17:28:01
Subject: Re: FDW API: don't like the EXPLAIN mechanism
Previous:From: Tom LaneDate: 2011-02-21 16:50:03
Subject: Re: FDW API: don't like the EXPLAIN mechanism

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group