Joachim Wieland <[EMAIL PROTECTED]> writes:
> Ok, the attached patch now does it correctly as suggested by Alvaro.
Applied with minor cleanup --- I thought the code for scanning for
dependent relations was unreasonably complicated and created
unpredictable locking order, so I simplified it.
On Fri, Feb 03, 2006 at 10:27:30AM -0500, Tom Lane wrote:
> Basically: it's the user's fault if he says "TRUNCATE t2" in a situation
> where the referent of t2 might be changing concurrently. But once
> you've identified t2, it's your fault if you don't track the
> dependencies of t2 correctly, ev
Joachim Wieland <[EMAIL PROTECTED]> writes:
> On Thu, Feb 02, 2006 at 12:34:28PM -0300, Alvaro Herrera wrote:
>> That's the wrong way to go about it -- better refactor the code so that
>> a function gets a list of Oids instead of RangeVars, and truncates them.
>> ExecuteTruncate should build the li
On Thu, Feb 02, 2006 at 12:34:28PM -0300, Alvaro Herrera wrote:
> > The patch also adds a function makeRangeVarFromRelId() to namespace.c
> > that I thought would be useful. I hope I didn't overlook something
> > similar that exists already.
> That's the wrong way to go about it -- better refactor
Joachim Wieland wrote:
> The proposed patch implements TRUNCATE ... CASCADE:
>
> * %Allow TRUNCATE ... CASCADE/RESTRICT
> This is like DELETE CASCADE, but truncates.
>
> The patch also adds a function makeRangeVarFromRelId() to namespace.c that I
> thought would be useful. I hope I didn't overl
The proposed patch implements TRUNCATE ... CASCADE:
* %Allow TRUNCATE ... CASCADE/RESTRICT
This is like DELETE CASCADE, but truncates.
The patch also adds a function makeRangeVarFromRelId() to namespace.c that I
thought would be useful. I hope I didn't overlook something similar that
exists alr
