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 1rmNJV-007VdM-35 for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Mar 2024 00:26:45 +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 1rmNJT-007nei-0j for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Mar 2024 00:26:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmNJS-007neY-ED for pgsql-hackers@lists.postgresql.org; Tue, 19 Mar 2024 00:26:43 +0000 Received: from 008.lax.mailroute.net ([199.89.1.11]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmNJM-005EOS-UM for pgsql-hackers@lists.postgresql.org; Tue, 19 Mar 2024 00:26:41 +0000 Received: from localhost (localhost [127.0.0.1]) by 008.lax.mailroute.net (Postfix) with ESMTP id 4TzCFn0yPtz6Cnk8s; Tue, 19 Mar 2024 00:26:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=mr01; t= 1710807995; x=1713399996; bh=FqdkUIpRdhvPXxHGUb+CvYR3HYTdhxoZq0B DeLBphyk=; b=m1DV54yZlpCNhifsEKMkB3Y+zaFiViN5BGB/CAYIOAIGPzpkizi L91/vHToplsrQlYOt1Hd6hToEikUV9gjwwooM64bE8QNo8lH1eCBU6r6IpND155Z 6Uq7adc3okSX+MtS5TbhRxsiTtXlvw7TFSmUj+syF8z+yOqr3jLqR8h+qG3rgDsd JiNRidc2HlZzogz1TzZFlnjkiYAAmFt3frO3UbgXHqDWUZ+4bN+7KS8HHjDYXjkE P5/g6AVNLSVborBNuQvHIZyXdItkynuXverDnx8CUsA+qqDBErJzFJzjHQkO3dW2 2y2B8XEdlIfFtd4ECdFT4Cdo/fQ+LAQnnHg== X-Virus-Scanned: by MailRoute Received: from 008.lax.mailroute.net ([127.0.0.1]) by localhost (008.lax [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id gheFIssoJbZD; Tue, 19 Mar 2024 00:26:35 +0000 (UTC) Received: from [73.103.120.3] (c-73-103-120-3.hsd1.in.comcast.net [73.103.120.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jcflack@acm.org) by 008.lax.mailroute.net (Postfix) with ESMTPSA id 4TzCFl2c1Dz6Cnk8m; Tue, 19 Mar 2024 00:26:35 +0000 (UTC) Subject: Re: Java : Postgres double precession issue with different data format text and binary To: Rahul Uniyal References: <7628237F-DEB2-414C-84D9-2E0C29FD9173@gmail.com> Cc: pgsql-hackers@lists.postgresql.org From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <65F8DBB9.9020107@acm.org> Date: Mon, 18 Mar 2024 20:26:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <7628237F-DEB2-414C-84D9-2E0C29FD9173@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Rahul, On 03/18/24 15:52, Rahul Uniyal wrote: > Since the column format is text and not binary it converts the value > to BigDecimal and give back the value as 40 . > ... > Now since the format is Binary ... it returns DOUBLE from there > result in 40.0 > > Now i am not sure for the same table and same column why we have two > different format and this issue is intermittent. I don't see, in this message or your earlier one, which public ResultSet API method your Java client code is calling. It sounds as if you are simply calling getObject, the flavor without a second parameter narrowing the type, and you are finding that the object returned is sometimes of class Double and sometimes of class BigDecimal. Is that accurate? That would seem to be the nub of the issue. You seem to have found that the class of the returned object is influenced by whether text or binary format was used on the wire. I will guess that would be worth reporting to the PGJDBC devs, using the pgsql-jdbc list. The question of why the driver might sometimes use one wire format and sometimes the other seems secondary. There may be some technical explanation, but it would not be very interesting except as an implementation detail, if it did not have this visible effect of changing the returned object's class. For the time being, I assume that if your Java code calls a more specific method, such as getObject(..., BigDecimal.class) or getObject(..., Double.class), or simply getDouble, you will get results of the desired class whatever wire format is used. The issue of the wire format influencing what class of object getObject returns (when a specific class hasn't been requested) is probably worth raising on pgsql-jdbc. Regards, -Chap