| 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: | Whole Thread | Raw Message | 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 |