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 lasttruncated in the current subtransaction
