At 01:06 24/06/01 -0400, Tom Lane wrote:
>
>The answer: the query has nothing to do with it. However, the
>deferred triggers you have on the target relation have a lot to do
>with it. It's all deferred-trigger-event storage.
Would it be worth using a local (system) temporary table for this sort
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Can one of you knowledgeable people tell me why current CVS as of
> a week ago would have the backend running this query grow to
> 600 meg+?
The answer: the query has nothing to do with it. However, the
deferred triggers you have on the target relat
As a matter of interest, whatever happened to Perter's & Jan's plans for
setuid functions?
>From memory, Jan's proposal was shelved in favour of something Peter had
previously proposed, is that right?
Philip Warner
Marko Kreen <[EMAIL PROTECTED]> writes:
> Question to -hackers: currently there is not possible to cast
> bytea to text and vice-versa. Is this intentional or bug?
Intentional. text and friends do not like embedded nulls.
If there were a cast it would have to be one that implies
an I/O convers
At 20:47 23/06/01 -0400, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> The term for user identity is "authorization", so I would
>> call these commands
>
>> SET AUTHORIZATION { INVOKER | DEFINER }
>
>I like that better, too.
>
I have not read the whole thread, but I am used t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The term for user identity is "authorization", so I would
> call these commands
> SET AUTHORIZATION { INVOKER | DEFINER }
I like that better, too.
Overall, the only objection I can see to doing things this way is that
we have to do it over again
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Still, it's an interesting alternative. Comments anyone?
> SelfExclusiveLock is clear and can't be confused with other lock types.
It could possibly be made a little less dangerous if "SelfExclusiveLock"
were defined to conflict with itself and Acces
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Isn't it a better idea to have a separate 'SELF EXCLUSIVE' lock
> which conflicts with only itself ?
>>
>> *Only* itself? What would that be useful for?
> Isn't VacuumLock = RowExclusiveLock + SelfExclusiveLock
> for the table ?
Oh, I see, you're
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Isn't it a better idea to have a separate 'SELF EXCLUSIVE' lock
> which conflicts with only itself ?
*Only* itself? What would that be useful for? Not for locking
tables, anyway --- if you don't conflict with AccessExclusiveLock
then it's possible f
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> No. I'm concerned that PostgreSQL should work out of the box for
> everyone.
Agreed.
> And I would prefer that PostgreSQL works the same on every
> platform out of the box.
Well, I'm not sure that we need to take that as far as saying that
default
10 matches
Mail list logo
