Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sNckY-009btZ-GO for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Jun 2024 18:24:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sNckW-009wXP-CE for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Jun 2024 18:24:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sNckV-009wXH-VH for pgsql-hackers@lists.postgresql.org; Sat, 29 Jun 2024 18:24:36 +0000 Received: from wfhigh4-smtp.messagingengine.com ([64.147.123.155]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sNckS-004BOV-Qu for pgsql-hackers@lists.postgresql.org; Sat, 29 Jun 2024 18:24:34 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id 9C28018000BD; Sat, 29 Jun 2024 14:24:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 29 Jun 2024 14:24:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719685469; x= 1719771869; bh=ck+9BinEZQgVb3i6TWLnUntHdeF2DVk4B9QH/XX4ePU=; b=u jmwC8EMmV0frsLyGF6QHdEeGVlsjFckEIr01nqukLn1FfWMA16kPybI3+sYdYSzn n/4grHy934vPWQdQ9wKrJE3s/hVjiMAMjE5rJHMQk1jRDKMbgeSM+Xad/teCByrL X9T2v7HlJEDC3WXDyojaO1GT+M0ISByjoweP3BUabWjrSY1/SCkkMxFZxxG90Glf +Y8do8nsSKz/dnVhpFQN3GIgcjMJCi1NOyhoroctEE2zSW1x/PJ3KeRpWSsJWqbe UOANmo7+Cs9X36Hx+ay43vDeUM5cNvMvM+pe5f6qdGI2wH7v06mkJzrRyUUh8t6v bXr8QNRHZbj2vgTi9AgwA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdelgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepfeeifedtfeffteekteeutddujeeukeeiudegffeiffet fefhjeefkedtjedvgedvnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh dpthhhvggurghilhihfihtfhdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 29 Jun 2024 14:24:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1719685467; bh=qR+pe4FoBD2oZxsoVXXIiHDELrrIWYcnyFO9X0YhlEE=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Eu+EJlKvcf/vJpQhn2b/Enbo3s/KwS0GKJyJ8EdKcmHuVYuj3AutBoaKxyqMuAwSg 0VHI8ZKpcGdHTkfplIQaQ/Hr34TeR9pZa/M9BsiulzxYyOKl984XozUkhf4J5z6o7h 2q9vMO42ACmrx1731EhIacVrKgWMMZPXFeQ2p1slJPAH3IWjJhJ64Z5xyg/0reHzj/ kExirqiyT1v+ugp/TWAH9XHVlOBPuC2uk/bfiLcklqwbm/j/+HAM6yKjZY+G6Qyayz CelVIDhnXQr83gAptxmbno4rPFOMjrLn/+UU+6rGJ2XloeBkAHt7frss0sr7egWB1d WJxZxiRC1YnKg== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 1665D52B; Sat, 29 Jun 2024 11:24:27 -0700 (PDT) Date: Sat, 29 Jun 2024 20:24:27 +0200 From: Alvaro Herrera To: Amit Langote Cc: jian he , Tom Lane , Peter Eisentraut , PostgreSQL Hackers Subject: Re: pgsql: Add more SQL/JSON constructor functions Message-ID: <202406291824.reofujy7xdj3@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c > index 233b7b1cc9..df766cdec1 100644 > --- a/src/backend/parser/parse_expr.c > +++ b/src/backend/parser/parse_expr.c > @@ -3583,6 +3583,7 @@ coerceJsonFuncExpr(ParseState *pstate, Node *expr, > Node *res; > int location; > Oid exprtype = exprType(expr); > + int32 baseTypmod = returning->typmod; > > /* if output type is not specified or equals to function type, return */ > if (!OidIsValid(returning->typid) || returning->typid == exprtype) > @@ -3611,10 +3612,19 @@ coerceJsonFuncExpr(ParseState *pstate, Node *expr, > return (Node *) fexpr; > } > > + /* > + * For domains, consider the base type's typmod to decide whether to setup > + * an implicit or explicit cast. > + */ > + if (get_typtype(returning->typid) == TYPTYPE_DOMAIN) > + (void) getBaseTypeAndTypmod(returning->typid, &baseTypmod); I didn't review this patch in detail, but I just noticed this tiny bit and wanted to say that I don't like this coding style where you initialize a variable to a certain value, and much later you override it with a completely different value. It seems much clearer to leave it uninitialized at first, and have both places that determine the value together, if (get_typtype(returning->typid) == TYPTYPE_DOMAIN) (void) getBaseTypeAndTypmod(returning->typid, &baseTypmod); else baseTypmod = returning->typmod; Not only because in the domain case the initializer value is a downright lie, but also because of considerations such as if you later add code that uses the variable in between those two places, you'd be introducing a bug in the domain case because it hasn't been set. With the coding I propose, the compiler immediately tells you that the initialization is missing. TBH I'm not super clear on why we decide on explicit or implicit cast based on presence of a typmod. Why isn't it better to always use an implicit one? -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Small aircraft do not crash frequently ... usually only once!" (ponder, http://thedailywtf.com/)