On 06.11.25 14:17, Peter Eisentraut wrote:
> On 05.11.25 19:19, Masahiko Sawada wrote:
>>> Attached is my proposed patch. I kept it similar to the recently
>>> committed fix in commit ba99c9491c4. Note that we also need to consider
>>> whole-row references, as that patch did.
>>
>> Here are some minor comments for the proposed patch:
>>
>> + ereport(ERROR,
>> + errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> + errmsg("generated columns are not
>> supported in COPY FROM WHERE conditions"),
>> + errdetail("Column \"%s\" is a generated
>> column.",
>> +
>> get_attname(RelationGetRelid(rel), attno, false)));
>>
>> How about using ERRCODE_INVALID_COLUMN_REFERENCE instead? It's more
>> consistent with other places where we check the column references.
>>
>> ---
>> --- a/src/test/regress/sql/copy2.sql
>> +++ b/src/test/regress/sql/copy2.sql
>> @@ -161,7 +161,6 @@ COPY x from stdin WHERE a IN (generate_series(1,5));
>>
>> COPY x from stdin WHERE a = row_number() over(b);
>>
>> -
>> -- check results of copy in
>> SELECT * FROM x;
>>
>> Unnecessary line removal.
>>
>> The rest looks good to me.
>
> Thanks. I have committed it with these corrections.
The commitfest entry associated with this thread is still open.
The result of the last commit is that generated columns are prohibited
in COPY WHERE expressions.
Earlier in the thread there were proposed patches to allow them to work.
At least for virtual generated columns this was relatively simple, for
stored generated columns it was harder because of the timing relative to
triggers.
After thinking about this some more, I think we should just not do that.
This seems fundamentally wrong, because generated columns are a
property of the target table, but the COPY WHERE clause is meant to
filter the input data. This means the practical use is already quite
questionable. And then as discussed the execution timing relative to
triggers and perhaps other things make this potentially pretty
complicated and semantically dubious.
