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 u
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
s
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 (
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:
> 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
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:
> 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 impos
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:
-
Bruce Momjian 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 normally mark S
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"
> stat
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 SQ
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 statement
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 th
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 protocol do not. This should probably be fixed,
>
> That's debat
"" <[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 s
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 intend
"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 q
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 protocol do not. This should probably be fixed,
but I can't see a clean way
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
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
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
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 colu
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 analyz
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 s/query/
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,
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 shoul
26 matches
Mail list logo
