Re: Allow pooled connections to list all prepared queries - Mailing list pgsql-patches

From David Brown
Subject Re: Allow pooled connections to list all prepared queries
Date
Msg-id 20041224203429.GA950@lan.spoonguard.org
Whole thread Raw
In response to Re: Allow pooled connections to list all prepared queries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Hi Tom:

On Fri, Dec 24, 2004 at 11:00:57AM -0500, Tom Lane wrote:
>>   * Extended PostgreSQL's SQL grammar to capture the original SQL query
>>   string for PREPARE statements.
>
>This seems much the ugliest and most invasive part of the patch.  I'd
>suggest doing something similar to what pg_proc.c is doing:

I agree. At the time I did this, I was working against the 7.4.5 release
(which, as far as I can tell, doesn't have ActivePortal defined anywhere).
I'll try your approach on a CVS snapshot.

>>   * Modified backend/commands/prepare.c to keep some additional
>>   statistics in the prepared statement hash table (plan creation time,
>>   execution count, etc.)
>
>The usefulness of this seems pretty dubious.  You aren't going to have a

>>   * Added an accessor function to allow for "raw" access to the prepared
>>   statement hash table (necessary for sequential access).
>
>It would have been better to put the function that needs this access
>into prepare.c.  There is no point in trying to hide a data structure
>inside a module if we then turn around and expose the data structure
>to the world...

I'll split the exec_count/gettimeofday stuff out into a separate patch, and
find a way to eliminate FetchPreparedStatementHtab().

Thanks,

- Dave


pgsql-patches by date:

Previous
From: David Brown
Date:
Subject: Re: Allow pooled connections to list all prepared queries
Next
From: David Brown
Date:
Subject: Re: Allow pooled connections to list all prepared queries