Re: [HACKERS] libpq and SPI

"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