From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
cc: sawada.mshk@gmail.com, d.koval@postgrespro.ru, dilipbalaut@gmail.com,
        andrewbille@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable
 transaction causes Assert at the transaction end
In-reply-to: <20220314.173000.398225758850773114.horikyota.ntt@gmail.com>
References: 
 <CAD21AoA2sivebwQw9602CBf8URFWGKY0=qE6=2wDkm2YhRKnOw@mail.gmail.com>
 <982894.1647028392@sss.pgh.pa.us>
 <CAD21AoBpW8i8TfNoCm_iSxSZ8eZp_Tf10q1h-7wDmWCPiXGYYw@mail.gmail.com>
 <20220314.173000.398225758850773114.horikyota.ntt@gmail.com>
Comments: In-reply-to Kyotaro Horiguchi <horikyota.ntt@gmail.com>
	message dated "Mon, 14 Mar 2022 17:30:00 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <170695.1647265517.1@sss.pgh.pa.us>
Date: Mon, 14 Mar 2022 09:45:17 -0400
Message-ID: <170696.1647265517@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/170696.1647265517%40sss.pgh.pa.us>
Precedence: bulk

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> ERRCODE_FEATURE_NOT_SUPPORTED doesn't look proper for the case. Isn't
> it ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE or something like?

Mmm ... I guess you could think of it that way, but it seems a
little weird, because you have to suppose that the *transaction*
not the GUC itself is the object that is in the wrong state.
We could use ERRCODE_ACTIVE_SQL_TRANSACTION as is done in
check_XactIsoLevel et al.  But this code is supposed to be generic,
and if there are ever any other GUCs marked NO_RESET, who's to say
if that would be appropriate at all for them?

I'm OK with FEATURE_NOT_SUPPORTED.

			regards, tom lane