Re: Virtual generated columns

On 28.11.24 10:35, Peter Eisentraut wrote:
> 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@eisentraut.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?

I have committed this, just to master for now.