Обсуждение: libpq and SPI

Hi,
   I have seen what I concider to be a bug in either the libpq library or
in the backend.  To see the effects, first, install the execq() function
from the SPI section of the Programmers Guide.  Then do this in psql:

template1=> select execq('create user fred', 1);
Backend sent D message without prior T
   At this point psql will hang.  I have a patch for libpq that fixes this
but I am not sure if this is the right place for it.  My questions are:  Is
it not reasonable to run "utility" queries from inside SPI?  Is the problem
in the client-side libpq interface or should something be done at the server
end?  If anyone is interested, I can explain why I want to do this.
   Any advice would be greatly appreciated.

Jerry

"Gerald L. Gay" <glgay@pass.korea.army.mil> writes:
>     I have seen what I concider to be a bug in either the libpq library or
> in the backend.  To see the effects, first, install the execq() function
> from the SPI section of the Programmers Guide.  Then do this in psql:

> template1=> select execq('create user fred', 1);
> Backend sent D message without prior T

That would be a backend bug, for sure.  It's a violation of the FE/BE
protocol to send data row(s) without sending a row description first.

>     At this point psql will hang.  I have a patch for libpq that fixes this
> but I am not sure if this is the right place for it.

I do not believe it is really possible to "ignore" this error inside
libpq.  Without the initial T message you have no idea how many fields
are in a row, and thus you cannot even parse a D message to skip over
it --- there's no way to know the length of the null-fields bitmap.

> Is it not reasonable to run "utility" queries from inside SPI?

Seems reasonable offhand, but I have no idea whether it really is or
not.  If the context that the SPI procedure is executing from is a
SELECT, as you illustrate above, then I could see where it would be
a bad idea to allow utility statements to execute before the SELECT
finishes.  (Examples of no-nos: altering or dropping tables that the
SELECT has already started using; VACUUM; perhaps other stuff.)

But either way it's definitely a backend bug: the SPI interface
should either handle utility statements or reject them cleanly.
        regards, tom lane