I admit I did it by experimentation but the Drop Table was failing because of existing dependencies and the "CASCADE" forced the dropping of the dependencies as well.  I'm not a postgres expert so thought I'd copy Jignesh and get his take on whether this is the wrong thing to do.  

On Feb 12, 2013, at 8:04 AM, Michael Minella wrote:

> In spring-batch-core/src/main/resources/org/springframework/batch/core/schema-drop-postgresql.sql:
> 
> > @@ -1,12 +1,12 @@
> >  -- Autogenerated: do not edit this file
> >  
> > -DROP TABLE  BATCH_STEP_EXECUTION_CONTEXT ;
> > -DROP TABLE  BATCH_JOB_EXECUTION_CONTEXT ;
> > -DROP TABLE  BATCH_STEP_EXECUTION ;
> > -DROP TABLE  BATCH_JOB_EXECUTION_PARAMS ;
> > -DROP TABLE  BATCH_JOB_EXECUTION ;
> > -DROP TABLE  BATCH_JOB_INSTANCE ;
> > +DROP TABLE  IF EXISTS BATCH_STEP_EXECUTION_CONTEXT CASCADE;
> > +DROP TABLE  IF EXISTS BATCH_JOB_EXECUTION_CONTEXT CASCADE;
> > +DROP TABLE  IF EXISTS BATCH_STEP_EXECUTION CASCADE;
> > +DROP TABLE  IF EXISTS BATCH_JOB_EXECUTION_PARAMS CASCADE;
> > +DROP TABLE  IF EXISTS BATCH_JOB_EXECUTION CASCADE;
> > +DROP TABLE  IF EXISTS BATCH_JOB_INSTANCE CASCADE;
> Are we sure we want the cascade on these? If I have a business schema that hangs off of one of these tables, won't this drop that as well? I'm thinking we would want our schemas to be as explicit as possible (only drop exactly what we create).
> 
> —
> Reply to this email directly or view it on GitHub.
> 
>