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. +