Re: Disallow USING clause when altering type of generated column

On 22.08.24 08:15, Yugo Nagata wrote:
> On Thu, 22 Aug 2024 11:38:49 +0800
> jian he <jian.universality@gmail.com> wrote:
> 
>> On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>>
>>
>> + /*
>> + * Cannot specify USING when altering type of a generated column, because
>> + * that would violate the generation expression.
>> + */
>> + if (attTup->attgenerated && def->cooked_default)
>> + ereport(ERROR,
>> + (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
>> + errmsg("cannot specify USING when altering type of generated column"),
>> + errdetail("Column \"%s\" is a generated column.", colName)));
>> +
>>
>> errcode should be ERRCODE_FEATURE_NOT_SUPPORTED?
> 
> 
> 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.

>> also
>> CREATE TABLE gtest27 (
>>      a int,
>>      b text collate "C",
>>      x text GENERATED ALWAYS AS ( b || '_2') STORED
>> );
>>
>> ALTER TABLE gtest27 ALTER COLUMN x TYPE int;
>> ERROR:  column "x" cannot be cast automatically to type integer
>> HINT:  You might need to specify "USING x::integer".
>>
>> should we do something for the errhint, since this specific errhint is wrong?
> 
> Yes. I think we don't have to output the hint message if we disallow USING
> for generated columns. Or, it may be useful to allow only a simple cast
> for the generated column instead of completely prohibiting USING.

Good catch.  Here is an updated patch that fixes this.

This got me thinking whether disallowing USING here would actually 
prevent some useful cases, like if you want to change the type of a 
generated column and need to supply an explicit cast, as the hint 
suggested.  But this actually wouldn't work anyway, because later on it 
will try to cast the generation expression, and that will fail in the 
same way because it uses the same coerce_to_target_type() parameters. 
So I think this patch won't break anything.  Maybe what I'm describing 
here could be implemented as a new feature, but I'm looking at this as a 
bug fix right now.