David Fetter <david@fetter.org> writes:
> On Thu, Feb 10, 2005 at 09:51:18PM -0500, Tom Lane wrote:
>> ... it loses the distinction between utility statements that
>> can return tuples and those that can't.
> Where is this distinction in SPI?
Well, the point is that there are potentially three types of statements
involved:
1. SELECTs
2. Utility statements that can return tuples (EXPLAIN, SHOW, etc)
3. Utility statements that can't return tuples (ALTER, etc)
The current SPI API is only designed to account for 1 and 3, failing to
consider 2 in any meaningful fashion. (In particular, there's really no
way to tell the difference between a 2-that-happened-to-return-zero-
rows-this-time and a 3.) This of course is because category 2 did not
exist at the time that SPI was designed.
The $64 question is whether anyone *needs* to make these distinctions.
If we arrange to return SPI_OK_SELECT for category 2, then callers won't
be able to tell the difference between categories 1 and 2, but on the
other hand a zero-row result set will still be properly classified as
a SELECT-like operation. If we leave the API as it stands today then a
zero-row result set looks like a category 3, which arguably is a worse
categorization.
I'm not sure that any of the statements in question actually can return
zero-row result sets today, but I think it would be bad to make these
decisions on the basis of assuming that the case will never arise.
regards, tom lane