From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | PQexecParams() returns PGRES_COMMAND_OK for empty query |
Date: | 2009-01-08 13:55:56 |
Message-ID: | 14674.1231422956@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-08 14:05:29 | Re: Sample of user-define window function and other things |
Previous Message | Cédric Villemain | 2009-01-08 13:46:42 | Re: ONLY with parentheses |