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
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 i
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:
> >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 cle
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_d
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
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 is
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
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
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.
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 d
11 matches
Mail list logo
