David Fetter <david@xxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
