Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qCSMQ-0008HK-M8 for pgsql-admin@arkaria.postgresql.org; Thu, 22 Jun 2023 22:01:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qCSMO-00071x-QW for pgsql-admin@arkaria.postgresql.org; Thu, 22 Jun 2023 22:01:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qCSMM-0006z1-Nx for pgsql-admin@lists.postgresql.org; Thu, 22 Jun 2023 22:01:00 +0000 Received: from mx0b-000e5c14.pphosted.com ([148.163.137.209]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qCSMI-0045my-Ak for pgsql-admin@lists.postgresql.org; Thu, 22 Jun 2023 22:00:57 +0000 Received: from pps.filterd (m0206231.ppops.net [127.0.0.1]) by mx0a-000e5c14.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35MIpAuT020665; Thu, 22 Jun 2023 17:00:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=express-scripts.com; h=from : to : cc : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version : subject; s=pod140124231234; bh=KxS6H/cUtrBiEdN24vgsoj6PexIqYcD7MuQ3FBk5P1M=; b=MAYGT8GvlS1KB25TscXAB+LnZoe/6ejCABlw+kvnxP/o1L8e5fwmAYpaEk3aOw4qJ+UN lzyHpfmpER/g4lq31EbmWicVCEkWVl4leiL3zXufs7L9xjiGjokwk+I2gcVFrkM51ssr Zb8adZMsuWMGFo/guoiKK+3dZ37cspLyexVOTHf5RSUjn1IOwlhqJLjl+V3gp6b1Wlmm /DD4AhF1rFKLhCm/Cs0U+NVaYW0Mjb9OP5XcNwKvfm76RCFMi0K2rcXhmgsztwYA2Azk lw34HKVyElSsOhvp8dChFgZqXlx8n0ByM9P9QN99WeVHp23W8AJYUNoXCFiXSoT9oWD4 BA== Received: from eiaappxp0007.gid.prd.globalcore.com ([170.48.0.130]) by mx0a-000e5c14.pphosted.com (PPS) with ESMTPS id 3rasehqcgv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Jun 2023 17:00:50 -0500 Received: from cvlappxp20755.internal.cigna.com (HELO PS2PW1012186.accounts.root.corp) ([10.36.52.91]) by EIAAPPXP0007.gid.prd.globalcore.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2023 22:00:47 +0000 Received: from PS2PW1012186.accounts.root.corp (10.221.225.154) by PS2PW1012186.accounts.root.corp (10.221.225.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Thu, 22 Jun 2023 18:00:47 -0400 Received: from PS2PW1012186.accounts.root.corp ([fe80::9fec:fffb:1381:33ad]) by PS2PW1012186.accounts.root.corp ([fe80::9fec:fffb:1381:33ad%6]) with mapi id 15.02.1118.026; Thu, 22 Jun 2023 18:00:47 -0400 From: "Wetmore, Matthew (CTR)" To: Tom Lane , "David G. Johnston" CC: Ilya Kosmodemiansky , "pgsql-admin@lists.postgresql.org" Thread-Topic: [EXTERNAL] Re: GENERATE AS Thread-Index: AdmlQrLyTyHk5PZ/Rt+vdgjgyKHjnQAJNXgAAABsLwAAAbq3gAAHF9UA Date: Thu, 22 Jun 2023 22:00:47 +0000 Message-ID: <754d7cd591b74c8585f6efb0f4aef81a@express-scripts.com> References: <7c48174f8ce449af8f3e875bdeca7150@express-scripts.com> <4108564.1687468505@sss.pgh.pa.us> In-Reply-To: <4108564.1687468505@sss.pgh.pa.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.222.252.1] x-proofpoint-routing: 000e5c14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: GENERATE AS X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-22_16,2023-06-22_02,2023-05-22_02 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I got his working. I understand everyone's great suggestions on functions and views, that's ho= w I would have done this, but my requirement was very specific to my org. This stemmed from a re-architecture from MSSQL, and had to stay as is for = MainFrame (I tried to get to change) Basically, you just can't use the time functions(), in the GENERATE you hav= e to create a separate column with default time that in my case (isn't used= by the other system, but gets defaulted on INSERT.) Wonky, yes, but it will work for my specific need. (I have whitewashed the= specific need for security, so if this seems simplified, it is.) Thanks for all the replies! ALTER TABLE matt add column matt_time timestamp without time zone default current_timestamp =09 ALTER TABLE matt add column matt_time2 timestamp without time zone default current_timestam= p=20 ALTER TABLE matt ADD column matt_minute NUMERIC GENERATED ALWAYS AS ((EXTRACT(MINUTE FROM m= att_time))::numeric -(extract(MINUTE FROM matt_time2))::numeric) stored =09 ALTER TABLE matt ADD column matt_hour NUMERIC GENERATED ALWAYS AS ((EXTRACT(HOUR FROM matt_= time))::numeric -(extract(HOUR FROM matt_time2))::numeric) stored =09 select * from auto_auth.matt "matt_time" "matt_time2" "matt_hour" "matt_minute" "2023-06-22 17:30:53.33997" "2023-06-22 17:36:27.356768" 0 -6 -----Original Message----- From: Tom Lane =20 Sent: Thursday, June 22, 2023 2:15 PM To: David G. Johnston Cc: Ilya Kosmodemiansky ; Wetmore, Matthew (CTR) ; pgsql-admin@lists.postgresql.org Subject: [EXTERNAL] Re: GENERATE AS "David G. Johnston" writes: > The problem here is not timezone related - it is more fundamental in=20 > that the stored data does not change but the expression, as time=20 > progresses, is going to give different values and thus make what is store= d incorrect. Right --- current_timestamp in a generation expression makes no sense. (There's also an issue about whether the surrounding calculation is timezon= e-dependent, but that could be fixed up. Depending on current time cannot = be.) You could create a view in which this value is an extra computed column, bu= t you can't do it as a stored generated column. regards, tom lane