From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disallow USING clause when altering type of generated column |
Date: | 2024-08-22 08:49:22 |
Message-ID: | b3fbd328-9481-4125-8f90-cc40c24b30d4@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22.08.24 09:59, Yugo NAGATA wrote:
>>> Although ERRCODE_INVALID_TABLE_DEFINITION is used for en error on changing
>>> type of inherited column, I guess that is because it prevents from breaking
>>> consistency between inherited and inheriting tables as a result of the command.
>>> In this sense, maybe, ERRCODE_INVALID_COLUMN_DEFINITION is proper here, because
>>> this check is to prevent inconsistency between columns in a tuple.
>>
>> Yes, that was my thinking. I think of ERRCODE_FEATURE_NOT_SUPPORTED as
>> "we could add it in the future", but that does not seem to apply here.
>
> + (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
> + errmsg("cannot specify USING when altering type of generated column"),
> + errdetail("Column \"%s\" is a generated column.", colName)));
>
> Do you thnik ERRCODE_INVALID_TABLE_DEFINITION is more proper than
> ERRCODE_INVALID_COLUMN_DEFINITION in this case?
COLUMN seems better here.
I copied TABLE from the "cannot alter system column" above, but maybe
that is a different situation.
From | Date | Subject | |
---|---|---|---|
Next Message | 陈宗志 | 2024-08-22 08:49:55 | Re: Some questions about PostgreSQL’s design. |
Previous Message | Alexandra Wang | 2024-08-22 08:36:31 | Re: Index AM API cleanup |