Re: COPY FREEZE has no warning

On Fri, Jan 25, 2013 at 11:55:12AM -0800, Jeff Janes wrote:
> On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> >>>> FWIW, and I won't annoy anyone further after this email, now that its
> >>>> deterministic, I still think that this should be an ERROR not a WARNING.
> >>
> >>> As the FREEZE is just an optimization, I thought NOTICE, vs WARNING or
> >>> ERROR was fine.  If others want this changed, please reply.
> >>
> >> The previous argument about it was "if you bothered to specify FREEZE,
> >> you probably really want/need that behavior".  So I can definitely see
> >> Andres' point.  Perhaps WARNING would be a suitable compromise?
> >
> > I'll vote for ERROR.  I don't see why this sound be a best-effort thing.
> >
>
> +1.  If I had no objection to my database getting stuffed to the gills
> with unfrozen tuples, I wouldn't have invoked the feature in the first
> place.
>
> As far as can tell, this ERROR/WARNING must occur immediately, because
> once the first tuple is inserted frozen it is too late to change ones
> mind.  So the problem can be immediately fixed and retried.
>
> Except, is there perhaps some way for the user to decide to promote
> WARNINGs to ERRORs on for a given command/transaction?

OK, updated patch attached that throws an error with a more specific
message.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +