Re: Virtual generated columns

On 12.11.24 17:08, Peter Eisentraut wrote:
> On 11.11.24 12:37, jian he wrote:
>> On Wed, Nov 6, 2024 at 12:17 AM Peter Eisentraut
>> <peter(at)eisentraut(dot)org> wrote:
>>>
>>> New patch version.  I've gone through the whole thread again and looked
>>> at all the feedback and various bug reports and test cases and made sure
>>> they are all addressed in the latest patch version.  (I'll send some
>>> separate messages to respond to some individual messages, but I'm
>>> keeping the latest patch here.)
>>
>> just quickly note the not good error message before you rebase.
>>
>> src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
>> (2) ;
>> ERROR:  unrecognized constraint subtype: 4
>> src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
>> (2) stored;
>> ERROR:  unrecognized constraint subtype: 4
>> src7=# create domain d_fail as int4 constraint cc GENERATED ALWAYS AS
>> (2) virtual;
>> ERROR:  unrecognized constraint subtype: 4
>>
>> reading gram.y, typedef struct Constraint seems cannot distinguish, we
>> are creating a domain or create table.
>> I cannot found a way to error out in gram.y.
>>
>> so we have to error out at DefineDomain.
>
> This appears to be a very old problem independent of this patch.  I'll
> take a look at fixing it.

Here is a patch.

I'm on the fence about taking out the default case. It does catch the
missing enum values, and I suppose if the struct arrives in
DefineDomain() with a corrupted contype value that is none of the enum
values, then we'd just do nothing with it. Maybe go ahead with this,
but for backpatching leave the default case in place?