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 1lqULT-0006um-4t for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Jun 2021 05:32:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lqULQ-0007MC-9k for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Jun 2021 05:32:08 +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 1lqULP-0007Km-RC for pgsql-hackers@lists.postgresql.org; Tue, 08 Jun 2021 05:32:08 +0000 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lqULJ-00009N-I9 for pgsql-hackers@postgresql.org; Tue, 08 Jun 2021 05:32:05 +0000 Received: by mail-pl1-x634.google.com with SMTP id u7so10012655plq.4 for ; Mon, 07 Jun 2021 22:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GPJ4SE27zfGcl7q31KZ7NnlUpnGQnd0bnxwUVrOqApo=; b=TfH9YaMTZLY/FKpgj+vPXu928TOrO5qajeeOCHXHb9X3LfY5BZlsVRcVXqCwnKnLY/ 93I6JmlDgn7dnTn7B6kaF5sNkK5Bl82T0Ovpc8foKql0W/iPsB1cpf+pW9GZl+TLSJFD r4dIzg71PrgfXRY0IjX8NAydzxhRdswP7XYRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GPJ4SE27zfGcl7q31KZ7NnlUpnGQnd0bnxwUVrOqApo=; b=E9NLSuppiIsKG41lSPKSSpCwqnYQeluQQEjbtwZ8u7UoaaOiVjsu/NtLZVYDDM6XIk b14uKVUtsYwEVLX+TJl18wc8L+doC6Eduyp9Uhui8WaKlzXCDlz4zOJ3dFOiUbjstl2t 4jhF08dJil+PSXzCkOR3jPgbGsXL8oC3nkW4Yvos8YzE0onrMlgh5tFwt8ZG1yn8xEiy hbWl5S8CCKBTo9AqK/ZGyCoPLhEVWEjPhspdUX9lrDz3h0nFAONa6Coe1Mx8trAc98Ui sIiNeQQhfTlUuggvYc8MNc1hFQx0SmM0wSkuBgIZ2Xyt7jtmaSp/g4Rn/N10dwhifyFc sc4g== X-Gm-Message-State: AOAM532wNeI6SU57O6ZHbYynfll3Ge3sjbvQoaX+myYrvNTgbHfXHtFL LYMtBiCBOs9V0x52yc/sOLC2Mw== X-Google-Smtp-Source: ABdhPJwMA9WUenQVAh+kukci7Jujup1sxgESSj8OD+nn1iJcPk7r5kMd1HX7Ldbf49mH7736ppzBzA== X-Received: by 2002:a17:90b:152:: with SMTP id em18mr21604347pjb.96.1623130319157; Mon, 07 Jun 2021 22:31:59 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id d18sm10126702pgm.93.2021.06.07.22.31.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jun 2021 22:31:58 -0700 (PDT) Date: Mon, 7 Jun 2021 22:31:55 -0700 From: Noah Misch To: Tom Lane Cc: Peter Eisentraut , Vik Fearing , Thomas Munro , Petr Fedorov , pgsql-hackers Subject: Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch Message-ID: <20210608053155.GB444080@rfd.leadboat.com> References: <428767b1-6a18-cc5a-bb2f-a78bc306fae3@postgresfriends.org> <6816.1590426450@sss.pgh.pa.us> <7994.1590428104@sss.pgh.pa.us> <298489.1604188643@sss.pgh.pa.us> <829899.1604357408@sss.pgh.pa.us> <1090402.1604449334@sss.pgh.pa.us> <20210606063331.GC297923@rfd.leadboat.com> <633566.1622990278@sss.pgh.pa.us> <650852.1622997506@sss.pgh.pa.us> <660576.1623006607@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <660576.1623006607@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Jun 06, 2021 at 03:10:07PM -0400, Tom Lane wrote: > I wrote: > > We could make use of COMPARE_COERCIONFORM_FIELD 100% correct by removing > > these two tests of the funcformat value, but on the whole I doubt that > > would be better. > > On still closer inspection, that seems like it'd be fine. All of > the gram.y productions that emit COERCE_SQL_SYNTAX also produce > schema-qualified function names (via SystemFuncName); and it seems > hard to see a use-case where we'd not do that. This makes the two > checks I cited 100% redundant, because the conditions they are in > also insist on an unqualified function name. So let's just take them > out again, making it strictly OK to use COMPARE_COERCIONFORM_FIELD. I have little intuition on this exact topic, but I have no particular concerns about the change you pushed.