On Tue, 2006-01-03 at 18:00 -0500, Neil Conway wrote:
Anyway, if there was a reasonably cheap way to present the query strings
of protocol-level and SQL prepared statements in the same manner, I
think we should definitely do so. Since there doesn't appear to be one,
I'm content to just use
Tom Lane wrote:
The average application that wants to use this view at all will be
looking to see did I already prepare FOO. If it's using the query
definition string for this purpose, comparing source text is easy
while comparing deparsed text to source is a nightmare.
Well, I don't see why
Neil Conway [EMAIL PROTECTED] writes:
In any case, if we use the query string as supplied by the user, how do
we produce that string in the case of SQL PREPARE? Manually stripping a
PREPARE ... AS prefix from the query string is difficult to do
robustly, but it seems (a) expensive (b)
Tom Lane wrote:
In practice, any given application will probably use one method to the
exclusion of the other, and wouldn't notice the inconsistency anyway.
If you are using both methods of preparing statements for some reason,
it's not improbable that you would want to know which way a given
Tom Lane wrote:
I object VERY strongly to the part of the patch that inserts a
deparse_query_list() call into exec_parse_message(). That is not a
cheap operation, and imposing that sort of overhead on every Parse
message is entirely unacceptable from a performance point of view.
Well, it
Neil Conway [EMAIL PROTECTED] writes:
Well, it doesn't insert a deparse_query_list() into the processing of
*every* Parse message -- it only does so for Parse messages that create
named prepared statements. I don't see that there is a fundamental
difference between a named Parse and an
Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
Attached is a revised version of this patch, based on some improvements
sent to me offlist by Joachim, as well as some code review and fixes by
myself. Changes:
Neil Conway [EMAIL PROTECTED] writes:
The docs need some improvement, but I'm not aware of any major remaining
issues with the patch.
I object VERY strongly to the part of the patch that inserts a
deparse_query_list() call into exec_parse_message(). That is not a
cheap operation, and imposing
Bruce Momjian wrote:
I have applied the following patch to CVS HEAD to mark client-side
prepare/bind/execute statements with [client] so they can be easily
distinguished from SQL commands.
There is no such thing as a client-side prepare/bind/execute
statement. The distinction is between
Neil Conway wrote:
Bruce Momjian wrote:
I have applied the following patch to CVS HEAD to mark client-side
prepare/bind/execute statements with [client] so they can be easily
distinguished from SQL commands.
There is no such thing as a client-side prepare/bind/execute
statement. The
Bruce Momjian pgman@candle.pha.pa.us writes:
daveg wrote:
Could I suggest the reverse? That is, leave client statements alone and
mark server side ones specially. It seems to me that client is the normal
case and leaving it alone would be less intrusive.
Uh, the problem is that we don't
On Fri, Dec 30, 2005 at 05:55:23PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
One minor irritation is that the query string of prepared statements
created via SQL has PREPARE ... AS prefixed to it, whereas statements
prepared via the FE-BE
daveg wrote:
On Fri, Dec 30, 2005 at 05:55:23PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
One minor irritation is that the query string of prepared statements
created via SQL has PREPARE ... AS prefixed to it, whereas statements
prepared
Michael Paesold [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, pursuant to comments about David's proposal just now --- why is the
patch using text at all, rather than reverse-compiling the prepared
statement's querytree?
Well, I think for the driver or application, to recognize queries as
On December 14, 4:58 pm Tom Lane [EMAIL PROTECTED] wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Well, I think for the driver or application, to recognize queries as
their own, it seems much easier if the query is given exaclty as it
was sent.
Depends on what the intended use of the
[EMAIL PROTECTED] writes:
It uses the query string that was already in the prepared queries hash
table. This one uses debug_query_string. I'm a poor student and can't
afford paying you a lunch, but I'd offer you a coke if you tell me why this
is wrong ;-)
(1) Multiple statements in same
On Mon, 2005-12-12 at 10:56 +0100, Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
I think we should also return the parameters of each prepared statement.
Probably the best way to do this is to add another column
Neil Conway wrote:
On Mon, 2005-12-12 at 10:56 +0100, Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
I think we should also return the parameters of each prepared statement.
Probably the best way to do
Neil Conway [EMAIL PROTECTED] writes:
One minor irritation is that the query string of prepared statements
created via SQL has PREPARE ... AS prefixed to it, whereas statements
prepared via the FE-BE protocol do not. This should probably be fixed,
That's debatable. Earlier today, I was busy
Neil Conway [EMAIL PROTECTED] writes:
One minor irritation is that the query string of prepared statements
created via SQL has PREPARE ... AS prefixed to it, whereas statements
prepared via the FE-BE protocol do not. This should probably be fixed,
but I can't see a clean way to do it: I think
Hi,
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
The patch adds a new SRF and a new view that contain all prepared queries
available in the session.
Besides the name of the plan and the actual query the view also displays
the timestamp
Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
The patch adds a new SRF and a new view that contain all prepared
queries available in the session.
This looks nice, but for consistency in naming, this should be
Peter Eisentraut wrote:
Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
The patch adds a new SRF and a new view that contain all prepared
queries available in the session.
This looks nice, but for
On Mon, Dec 12, 2005 at 12:32:09PM +0100, Peter Eisentraut wrote:
Joachim Wieland wrote:
* %Allow pooled connections to list all prepared queries
This looks nice, but for consistency in naming, this should be about
prepared *statements*.
Okay, the appended patch is basically a
On Tue, 2005-12-13 at 00:39 +0100, Joachim Wieland wrote:
Okay, the appended patch is basically a s/query/statement/g.
Barring any objections, I'll review and apply the patch later this week.
-Neil
---(end of broadcast)---
TIP 6: explain
25 matches
Mail list logo
