On Feb 21, 2011, at 10:11 AM, David E. Wheeler wrote:
> Oops, sorry, make that
>
> https://github.com/pgexperts/explain-table
And now I've renamed it (sorry) and released it on PGXN. New links:
https://github.com/pgexperts/explanation
http://master.pgxn.org/dist/explanation/
Best,
David
On Feb 21, 2011, at 10:07 AM, David E. Wheeler wrote:
> See also
>
> https://github.com/theory/explain-table
Oops, sorry, make that
https://github.com/pgexperts/explain-table
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Feb 21, 2011, at 9:12 AM, Andrew Dunstan wrote:
> 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 matchi
On 02/21/2011 12:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
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.
Well, sure we can. B
Andrew Dunstan writes:
> 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.
Well, sure we can. But if you're using any external FDW,
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 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
Alvaro Herrera writes:
> Excerpts from Andrew Dunstan's message of lun feb 21 13:11:25 -0300 2011:
>> 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 som
On 02/21/2011 11:38 AM, Andrew Dunstan wrote:
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan 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
Excerpts from Andrew Dunstan's message of lun feb 21 13:11:25 -0300 2011:
> 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.
> Ma
On 02/21/2011 11:23 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/19/2011 11:07 PM, Tom Lane wrote:
However, it occurs to me that as long as we're passing the function the
ExplainState, it has what it needs to add arbitrary EXPLAIN result
fields.
If we allow the invention of new explain
Andrew Dunstan writes:
> On 02/19/2011 11:07 PM, Tom Lane wrote:
>> However, it occurs to me that as long as we're passing the function the
>> ExplainState, it has what it needs to add arbitrary EXPLAIN result
>> fields.
> If we allow the invention of new explain states we'll never be able to
>
On 02/19/2011 11:07 PM, Tom Lane wrote:
However, it occurs to me that as long as we're passing the function the
ExplainState, it has what it needs to add arbitrary EXPLAIN result
fields. Although it could do this the hard way, we could make it a lot
easier by exporting the ExplainProperty fu
On Sat, Feb 19, 2011 at 11:07 PM, Tom Lane wrote:
> Anybody have an objection to doing it like that?
I don't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
I wrote:
> ... I think we should drop
> FdwPlan.explainInfo and instead define an additional callback function
> that is called by EXPLAIN to produce the extra data for EXPLAIN to
> display. This function could have access to the EXPLAIN options as well
> as (in ANALYZE mode) the final state of th
14 matches
Mail list logo