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.
> Robert Treat wrote:
> > On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> > > > (7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE".
> > > > That seems very risky to me. I wonder if the risk is worth adding this
> > > > feature.
> > >
> > > I wouldn't care for that either. The prior suggestion of "TRUNCATE tab
> > > CASCADE" (to truncate any tables with FK dependencies on the original
> > > target, instead of failing) seems more reasonable.
> > >
> >
> > Actually there seems to be an ancillary issue here:
> >
> > 21809=# truncate exception;
> > ERROR: TRUNCATE cannot be used as table exception_notice_map references
> > this one via foreign key constraint $1
> > 21809=# TRUNCATE exception_notice_map ;
> > TRUNCATE TABLE
> > 21809=# truncate exception;
> > ERROR: TRUNCATE cannot be used as table exception_notice_map references
> > this one via foreign key constraint $1
> > 21809=# select count(*) from exception_notice_map;
> > count
> > -------
> > 0
> > (1 row)
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
