From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | adrien(dot)gilmore+pg(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error |
Date: | 2022-01-21 17:36:44 |
Message-ID: | 1196187.1642786604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Japin Li <japinli(at)hotmail(dot)com> writes:
> On Fri, 21 Jan 2022 at 17:22, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>> The error message content returned is what I suspect of being a bug, not 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-01-21 20:42:28 | Re: Further information on BUG #17299: Exit code 3 when open connections concurrently (PQisthreadsafe() == 1) |
Previous Message | Japin Li | 2022-01-21 17:27:55 | Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error |