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-29 07:15:51 |
Message-ID: | 7964fa14-8eda-401b-b860-766ad1cf5543@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22.08.24 10:49, Peter Eisentraut wrote:
> 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.
Committed and backpatched, with that adjustment.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2024-08-29 07:25:59 | Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM |
Previous Message | Heikki Linnakangas | 2024-08-29 07:01:34 | Re: Little cleanup of ShmemInit function names |