On Sat, 22 Jan 2022 at 01:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Right.
> Maybe it'd be sufficient to check for an active ALTER TABLE in the
> parser, but I'm not sure.
>
Do you mean check the table is accessed by ALTER TABLE when calling SPI to
execute the function? How can we get the table that is be accessed by
ALTER TABLE in parser?
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
