On Thu, Feb 10, 2005 at 10:30:26PM -0500, Tom Lane wrote:
> 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)
<snip>
> 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.
It occurs to me that distinguishing between 2 and 3 would be useful,
since knowing if there were zero rows returned or nothing should be
returned is a useful distinction. But in the general case, cases 1 and
2 can be distinguished by examining the sent query.
I guess it turns out that "type-of-statement" and "returns-tuples" are
orthoganal concepts and nobody realised this at the time.
> 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.
What's the right response to "SHOW nonexistant_variable;" ? Currently
it's an error return, which seems reasonable.
I can imagine that there are situations where it would be useful to be
able to extract the output of VACUUM and ANALYZE as resultsets.
However, there's no way for a client to signal it wants a result set.
And just changing the output stops it being logged.
Not an easy choice.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.