On Sun, 2003-08-17 at 00:42, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Sun, 17 Aug 2003, Bruce Momjian wrote:
> >> Is this a bug?
>
> > I don't think so. I'd say this is the expected behavior. Part of the
> > point is that it fails without checking for matching rows.
>
> To do anything else, you'd have to solve some locking and/or
> race-condition problems: rows could be inserted in the other table
> while the TRUNCATE runs.
>
Seems like you'll have that issue with truncate all wont you? I guess
we'll assume that if you use the cascade statement you understand these
risks and accept them.
Really my previous email was simply to point out to anyone implementing
the truncate cascade that truncate currently doesn't care if there is
really any data in the dependent tables, just that there are dependent
tables.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
