Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error |
| Дата | |
| Msg-id | 1196187.1642786604@sss.pgh.pa.us обсуждение |
| Ответ на | Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error (Japin Li <japinli@hotmail.com>) |
| Ответы |
Re: BUG #17376: Adding unique column with a function() default results in "could not read block 0 in file" error
|
| Список | pgsql-bugs |
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, 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
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера