David Fetter <david@xxxxxxxxxx> writes: > On Thu, Feb 10, 2005 at 08:11:42PM -0500, Tom Lane wrote: >> 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. > This doesn't sound good. It does seem like it's obscuring a distinction that some callers might care about. On the other hand, it would be a localized solution. >> 2. Leave SPI_execute alone and fix the callers. > By "fix the callers," do you mean "outfit them with SPI cursor > features," or something else? I meant teach them to accept rows when the result is either OK_SELECT or OK_UTILITY. I'm not volunteering to cursor-ify all the PLs ;-) ... not that I have anything against it, it's just not high on my own to-do list. > How big a job would this be? Big, I would think; in most cases it would mean defining a new API to expose to users of the PL, no? >> 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... > This sounds *really* bad. It's the only one that really preserves a clean distinction between the various cases. After thinking it over, I realize that #2 would affect user code too, since the knowledge that SPI_OK_UTILITY might imply rows are available would propagate right up to anything that could see the result code. (Exposing that code to plperl users might not have been such a hot idea, but I suppose it's done now.) So I now do not like #2: it saves nothing in terms of the amount of code we have to touch, and it loses the distinction between utility statements that can return tuples and those that can't. The realistic alternatives are #1 (small code change, but a bit ugly) and #3 (lots of code change, but preserves a distinction that some people may care about). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx
