Re: Understanding EXPLAIN ANALYZE output - Mailing list pgsql-general

From Tom Lane
Subject Re: Understanding EXPLAIN ANALYZE output
Date
Msg-id 5014.1108084302@sss.pgh.pa.us
Whole thread Raw
In response to Re: Understanding EXPLAIN ANALYZE output  (Michael Fuhr <mike@fuhr.org>)
Responses Re: Understanding EXPLAIN ANALYZE output  (David Fetter <david@fetter.org>)
List pgsql-general
Michael Fuhr <mike@fuhr.org> writes:
> Do PL/Perl and the other PLs require any changes to make this work?
> I tried $rv = spi_exec_query("EXPLAIN $query") but $rv contained
> only the following:

> $rv->{processed} = 0
> $rv->{status} = SPI_OK_UTILITY

Looking around, it seems that the PLs (and a lot of contrib modules) are
using SPI_execute rather than the SPI cursor features --- which is what
I fixed.  It looks from the code like SPI_execute does the right things
in terms of returning a tuple table, but it returns completion code
SPI_OK_UTILITY; and these callers only expect there to be result rows
when SPI_execute returns SPI_OK_SELECT.

Seems we have three possibilities to fix this:

1. Alter SPI_execute to say SPI_OK_SELECT after executing a utility
statement that returns tuples.

2. Leave SPI_execute alone and fix the callers.

3. Invent a new result code (SPI_OK_UTILITY_TUPLES maybe?) to return
in this case ... which means changing both SPI_execute *and* the
callers.  It would probably even propagate up to user code, since plperl
for one exposes the set of SPI result codes...

None of these seem especially attractive :-(.  Any thoughts?

            regards, tom lane

pgsql-general by date:

Previous
From: "Ed L."
Date:
Subject: Re: Understanding EXPLAIN ANALYZE output
Next
From: David Fetter
Date:
Subject: Re: Understanding EXPLAIN ANALYZE output