While checking out Rushabh Lathia's recent report I noticed $subject.
This is inconsistent because PQexec() returns PGRES_EMPTY_QUERY.
Is it something we should fix, or leave well enough alone on backward
compatibility grounds?
The cause seems to be that the backend (correctly) returns a NoData
response to libpq's Describe Portal command, and when pqParseInput3
sees that it forcibly initializes conn->result to a PGRES_COMMAND_OK
result, and then when it gets the 'I' (empty query) result to the
Execute message, it won't override the preset result. So there seem
to be two possible fixes:
1. 'n' processing shouldn't set up conn->result unless queryclass is
PGQUERY_DESCRIBE. (AFAICS, the cases where such a result is actually
desired should all be handled by a later 'C' message.)
2. 'I' processing should override any existing result.
#2 seems a bit brute-force, but I'm slightly worried about unexpected
side-effects from #1 --- I don't remember all the possible paths through
this state machine ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
