| 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: | Whole Thread | Raw Message | 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 |