Alvaro Herrera wrote:
Marko Kreen escribió:
On 3/30/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
In any case it's not likely that there are going to be thousands of
prepared statements, so is this really an issue?
I think the issue is here that its very common thing to do,
so open-coding it
Neil Conway escribió:
As to the implementation, calling hash_remove() in a loop seems a pretty
unfortunate way to clear a hash table -- adding a hash_reset() function
to the dynahash API would be cleaner and faster.
I wonder why hash_drop cannot be used?
--
Alvaro Herrera
On 3/30/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Neil Conway escribió:
As to the implementation, calling hash_remove() in a loop seems a pretty
unfortunate way to clear a hash table -- adding a hash_reset() function
to the dynahash API would be cleaner and faster.
I wonder why hash_drop
Marko Kreen escribió:
On 3/30/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Neil Conway escribió:
As to the implementation, calling hash_remove() in a loop seems a pretty
unfortunate way to clear a hash table -- adding a hash_reset() function
to the dynahash API would be cleaner and
On 3/30/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
If by destruction you mean something different than pfree, then maybe
hash_remove in a loop is the best solution, the other idea being passing
a function pointer to hash_destroy_deep to call on each element, which
is probably too messy an API.
Marko Kreen escribió:
On 3/30/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
In any case it's not likely that there are going to be thousands of
prepared statements, so is this really an issue?
I think the issue is here that its very common thing to do,
so open-coding it everywhere is waste,
Marko Kreen wrote:
Then a pooler argument: there is one pooler where RandomJoe executes
queries and another for specific app where the subset of SQL it uses is
known. I want to RESET only specific things in app case. So it would be
good if the RESET-s for specific areas would be available.
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
I agree with the other comments that RESET SESSION
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Huh, didn't we have a RESET SESSION command to do
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new client starts preparing statements again.
Huh,
On 3/27/07, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Marko Kreen wrote:
When pooling connections where prepared statements are in use,
it is hard to give new client totally clean connection as
there may be allocated statements that give errors when
new
11 matches
Mail list logo
