Re: [HACKERS] libpq and SPI

"Gerald L. Gay" <glgay(at)pass(dot)korea(dot)army(dot)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