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.
> 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.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
