Matthew <[EMAIL PROTECTED]> writes:
>> The correct fix is CommandCounterIncrement() in the DROP USER loop,
>> so that later iterations can see the changes made by prior iterations.
> Since postgre now suppport referential integrity and cascading deletes,
> wouldn't it make more sense to use that
Matthew <[EMAIL PROTECTED]> writes:
> Should I check out the current pre 7.0.3 CVS and test?
Sure, the more the merrier ...
regards, tom lane
>-Original Message-
>From: Tom Lane
>The correct fix is CommandCounterIncrement() in the DROP USER loop,
>so that later iterations can see the changes made by prior iterations.
>
> regards, tom lane
Since postgre now suppport referential integrity and cascading dele
>From: Tom Lane
>Fixed in current and back-patched for 7.0.3.
>
> regards, tom lane
Should I check out the current pre 7.0.3 CVS and test? If so I think you
gave the CVS information in a few previous emails on the hackers list so I
will look there for it.
Thanks for the qu
Matthew <[EMAIL PROTECTED]> writes:
>> Anyway, any comments? Can anyone else repeat this? I hope this is easy to
>> fix. I guess the quick fix is to disallow multiple users to be specified
>> in the drop user command.
The correct fix is CommandCounterIncrement() in the DROP USER loop,
so that
Matthew <[EMAIL PROTECTED]> writes:
>> I think we have found a bug in postgresql 7.0.2.
Bug confirmed --- on a compilation with Asserts enabled, this sequence
causes an assert failure during update of pg_group_name_index in the
DROP USER command, in both 7.0.* and current sources. I ran out of
s
> I think we have found a bug in postgresql 7.0.2. If I'm right then a fix
> for this should probably be added to 7.0.3 also. Anyway without further
> adieu:
>
> I have attached detail of my session at the end of this email, but the
> summary is as follows.
>
> If I run the following commands
