Re: COPY FREEZE has no warning

On Fri, Feb 01, 2013 at 12:57:18PM -0500, Bruce Momjian wrote:
> On Tue, Jan 29, 2013 at 08:34:24PM -0500, Noah Misch wrote:
> > On Fri, Jan 25, 2013 at 11:28:58PM -0500, Bruce Momjian wrote:
> > > 	BEGIN;
> > > 	TRUNCATE vistest;
> > > 	SAVEPOINT s1;
> > > 	COPY vistest FROM stdin CSV FREEZE;
> > > 	ERROR:  cannot perform FREEZE because of previous table activity in the current transaction
> > > 	COMMIT;
> > > 
> > > Clearly it was truncated in the same transaction, but the savepoint
> > > somehow invalidates the freeze.  There is a C comment about it:
> > 
> > The savepoint prevents the COPY FREEZE, because COPY FREEZE needs the table to
> > have been created or truncated in the current *sub*transaction.  Issuing
> > "RELEASE s1" before the COPY makes it work again, for example.
> > 
> > > 
> > >      * BEGIN;
> > >      * TRUNCATE t;
> > >      * SAVEPOINT save;
> > >      * TRUNCATE t;
> > >      * ROLLBACK TO save;
> > >      * COPY ...
> > 
> > This is different.  The table was truncated in the current subtransaction, and
> > it's safe in principle to apply the optimization.  Due to an implementation
> > artifact, we'll reject it anyway.
> 
> OK, so, should we change the error message:
> 
> 	cannot perform FREEZE because of transaction activity after table
> 	creation or truncation
> 
> to
> 
> 	cannot perform FREEZE because the table was not created or
> 	truncated in the current subtransaction
> 
> or do we need to keep the "transaction activity" weasel wording because
> of the second case you listed above?  I am suspecting the later.

Let's touch on the exception in passing by using the phrase "last truncated",
giving this wording for both the second and the third COPY FREEZE error sites:

	cannot perform FREEZE because the table was not created or last
	truncated in the current subtransaction