From: Tom Lane <tgl@sss.pgh.pa.us>
To: Japin Li <japinli@hotmail.com>
cc: adrien.gilmore+pg@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17376: Adding unique column with a function() default
 results in "could not read block 0 in file" error
In-reply-to: 
 <MEYP282MB166905F8F98ED50AD619CB54B65B9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
References: <17376-07b867ccc817828f@postgresql.org>
 <MEYP282MB166905F8F98ED50AD619CB54B65B9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM>
Comments: In-reply-to Japin Li <japinli@hotmail.com>
	message dated "Sat, 22 Jan 2022 01:27:55 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1196186.1642786604.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 21 Jan 2022 12:36:44 -0500
Message-ID: <1196187.1642786604@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1196187.1642786604%40sss.pgh.pa.us>
Precedence: bulk

Japin Li <japinli@hotmail.com> writes:
> On Fri, 21 Jan 2022 at 17:22, PG Bug reporting form <noreply@postgresql.=
org> wrote:
>> The error message content returned is what I suspect of being a bug, no=
t so
>> much that this SQL didn't work.

> +1. The error message makes user confused IMO, maybe we can fix it, but =
I have
> no idea for this.  Any suggestion is welcomed.

Yeah.  Ideally we'd throw an error along the lines of "can't access a
table that's in process of being altered".  The SELECT inside the function
is not part of the ALTER TABLE machinery and ought to be locked out.
However, I fear we don't have adequate infrastructure to tell which
table accesses *are* part of the ALTER TABLE machinery and which aren't.
Maybe it'd be sufficient to check for an active ALTER TABLE in the
parser, but I'm not sure.

			regards, tom lane