Re: COPY FREEZE has no warning - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: COPY FREEZE has no warning
Date
Msg-id CAMkU=1xVxjuhORdLxOn35WhVZS+JTdAw5arO2JXyhtAawM_MMw@mail.gmail.com
Whole thread Raw
In response to Re: COPY FREEZE has no warning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: COPY FREEZE has no warning
List pgsql-hackers
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?

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: LATERAL, UNNEST and spec compliance
Next
From: Kohei KaiGai
Date:
Subject: Re: allowing privileges on untrusted languages