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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: FDW API: don't like the EXPLAIN mechanism
Дата
Msg-id 4D629CE4.7000300@dunslane.net
обсуждение исходный текст
Ответ на Re: FDW API: don't like the EXPLAIN mechanism  (Mark Mielke <mark@mark.mielke.cc>)
Ответы Re: FDW API: don't like the EXPLAIN mechanism  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: FDW API: don't like the EXPLAIN mechanism  ("David E. Wheeler" <david@kineticode.com>)
Список 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@dunslane.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.


cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: FDW API: don't like the EXPLAIN mechanism
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FDW API: don't like the EXPLAIN mechanism