| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | "Dmitriy Igrishin *EXTERN*" <dmitigr(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Re: [HACKERS] Frontend/backend protocol improvements proposal (request). |
| Date: | 2013-06-24 14:08:24 |
| Message-ID: | 13031.1372082904@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
> Why do you need to track prepared statements on the client side?
The proposed change would fail to allow that anyway; consider the
possibility of a server-side function doing one or more PREPAREs or
DEALLOCATEs. The command tag would be completely inadequate for
reporting that.
Space is also a problem, since existing clients expect the tags to be
pretty short --- for instance, libpq has always had a hard-wired limit
of 64 bytes (CMDSTATUS_LEN) on what it can store for the tag. That's
not enough for a command name plus a full-length identifier.
If we were to try to do this, we'd need to invent some other reporting
mechanism, perhaps similar to ParameterStatus for GUC_REPORT variables.
But that would be a protocol break, which means it's unlikely to happen
anytime soon.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ziggy Skalski | 2013-06-24 14:17:21 | Re: .pgpass being ignored |
| Previous Message | Dmitriy Igrishin | 2013-06-24 13:55:23 | Re: [HACKERS] Frontend/backend protocol improvements proposal (request). |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-06-24 14:17:52 | Re: [Review] Re: minor patch submission: CREATE CAST ... AS EXPLICIT |
| Previous Message | Andres Freund | 2013-06-24 14:06:32 | Re: Support for REINDEX CONCURRENTLY |