From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | David Fetter <david(at)fetter(dot)org>, "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Understanding EXPLAIN ANALYZE output |
Date: | 2005-02-11 01:11:42 |
Message-ID: | 5014.1108084302@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michael Fuhr <mike(at)fuhr(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-02-11 02:14:50 | Re: Understanding EXPLAIN ANALYZE output |
Previous Message | Ed L. | 2005-02-11 00:43:35 | Re: Understanding EXPLAIN ANALYZE output |