Feedback-ID: ie0a040ee:Fastmail
Message-ID: <cfc3106f-40f1-4895-8b8a-873d3cf2db48@eisentraut.org>
Date: Tue, 3 Dec 2024 14:37:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Virtual generated columns
From: Peter Eisentraut <peter@eisentraut.org>
To: jian he <jian.universality@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
 Dean Rasheed <dean.a.rasheed@gmail.com>
References: <a368248e-69e4-40be-9c07-6c3b5880b0a6@eisentraut.org>
 <CACJufxGh=XX7q5xTci---HikSJsOwP7_qCNyyDHdp2YL4NLZCg@mail.gmail.com>
 <CACJufxHxoz_KVQxcQ=cSvJc+PNbh=FaHbcMZCOisoOaGAgjy4w@mail.gmail.com>
 <732a9543-0312-4f0c-a471-857b507a3546@eisentraut.org>
 <ebd1e0e9-115f-4dfa-98b8-e9b8e2f9eb2d@eisentraut.org>
 <CAEZATCV=RX0M58-uqSR6tFjwQAFnEcx3hvW-9ZZfRQJLg5LzRw@mail.gmail.com>
 <0f811f71-8c86-4e1b-b3bb-6a535674a440@eisentraut.org>
 <CAEZATCU3q=znAL7X1aSxuMpjfSyB1cT5j398HPb9ix9ci_HUqA@mail.gmail.com>
 <cd7c0fea-6c4b-4bdd-af3b-4d4dabb32ca1@eisentraut.org>
 <CAEZATCVLfMzNwT1J0bnvtv6YbmNSN9QSXb+1QSGyX6vK4q67Ow@mail.gmail.com>
 <ef7c466d-e3b9-4d60-bc03-cd9b48581442@eisentraut.org>
 <09800cb1-43aa-4239-8918-46b71ede4900@eisentraut.org>
 <536b281b-2cb3-4477-971f-c64838bc6263@eisentraut.org>
 <CACJufxF8fmM=Dbm4pDFuV_nKGz2-No0k4YifhrF3-rjXTWJM3w@mail.gmail.com>
 <41f64e3c-db80-43b2-9a21-7ecc515f889f@eisentraut.org>
 <c44f28a7-542c-4044-b8b2-d578bd4e9926@eisentraut.org>
Content-Language: en-US
In-Reply-To: <c44f28a7-542c-4044-b8b2-d578bd4e9926@eisentraut.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/cfc3106f-40f1-4895-8b8a-873d3cf2db48%40eisentraut.org>
Precedence: bulk

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.