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 1sy9lU-00ElWV-Bv for pgadmin-hackers@arkaria.postgresql.org; Tue, 08 Oct 2024 12:56:36 +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 1sy9lS-008RLt-LH for pgadmin-hackers@arkaria.postgresql.org; Tue, 08 Oct 2024 12:56:34 +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 1sy9lS-008RL9-Cu for pgadmin-hackers@lists.postgresql.org; Tue, 08 Oct 2024 12:56:34 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sy9lM-00398U-R5 for pgadmin-hackers@postgresql.org; Tue, 08 Oct 2024 12:56:30 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-2872134c806so1737195fac.3 for ; Tue, 08 Oct 2024 05:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1728392188; x=1728996988; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=PYz8NlkwGw+e1zAev4zGJw0g5LKFBp97h3InIjsOvlU=; b=ZMnQBcT8exA1nLZxRBWEL38ClO0W33h/S7T7vLeeVZHxSQCYwwlgFmFsQ1Zk0oR7g+ 2itHA8MTo2ShCY1LKZAlvf2ZUY4dMuYh5xLk/x9exKkGGXazO0kVrODHkxFAt1AaW2vE J36NMJfG18HQpKYKBkz9megOSIGmIf/ZPQrELh8X6x9mm/YdN0VNpynz8xRZ+kp5Wo02 v1wtzxvBfc1loKZVD9EWfjhAELTwoheJ5OfbvIEXSplBGB2dL5sEeE5wq+pAxkYlrcft qUdI8Hy9gNkzzNG9C2HKtRA8e3lnmcvFjLYKKfYAykOsN8x2VBFrDdcQ/1seTBezh7H2 AmHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728392188; x=1728996988; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PYz8NlkwGw+e1zAev4zGJw0g5LKFBp97h3InIjsOvlU=; b=Td3w0NEleJb9SAaaORg0mIOCtk6RDlU245Ynt7KNCPpptDP09P0UJQ72yL5+IbKdbV JTlTb08+noFTW9PEIZIMaSiM8kKrCEsKJu3+xmsoTjCYvnkppgZOaLFvZ4vupDtv2/Vu RQMR52vfhA0N7HrkKDfOMowITEMLSBFebFnNVw0XKW5CYYQ/f6Zla9LDDqbQCbBrQTz/ phE/uwSc1HTQuvEptnXrzwHSEt23cPzsY15osqRcor2ulAOMIroZHg2GoOSQwKvAiEdC jpmr0sgq6GkyXNnMqjJAD5jcH4XsqnZXCbSyQjTtG/XczgLJuqrIsga4jVxin4KLwlR4 xj1w== X-Gm-Message-State: AOJu0YxOZ9BTk/aXHT+KAHu4n5AIpouSBaFTzpq/w5j5XaIfqR4KNx71 b6qyMtxfksqEsMTK9olQV3tKHWQWLYBf/UPey9UWDwGSbU1KBbNkfPPYpABserCx4HD7ipo8VL0 GfIx1FnxGzSpWDFixJk92mqkeZ8vWRxPtGGXz3bBNUHelx44= X-Google-Smtp-Source: AGHT+IHynOomRvsv2hTtttu0pSkTjsU30a+wIApYCudVzg/HMjtdDVRdP9ObpfIzLc2olVU8ecL5wIpGJVV6Y9Zyfws= X-Received: by 2002:a05:6870:6589:b0:270:1eca:e9fd with SMTP id 586e51a60fabf-287c1d3fbe5mr9331198fac.3.1728392187732; Tue, 08 Oct 2024 05:56:27 -0700 (PDT) MIME-Version: 1.0 From: Pravesh Sharma Date: Tue, 8 Oct 2024 18:26:16 +0530 Message-ID: Subject: Require suggestion for issue #8007 To: pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="00000000000061fdab0623f6aa07" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000061fdab0623f6aa07 Content-Type: text/plain; charset="UTF-8" Hi Hackers, We have been working on issue #8007 . After our analysis, we found that the length and scale of the argument's data type are not stored in the database server, making it difficult to fetch. In the debugger, pgAdmin typecasts the provided value to its data type when calling the function, which is causing the issue. If we typecast the value to a character without specifying the length, it is treated as a character (1) (character of length 1). For example, the output of SELECT 'pgadmin', 'pgadmin'::character; is different. There are two solutions we can consider: 1. Do not typecast if the data type is character. 2. Typecast to varchar when the data type is character. Please provide your suggestions which solution looks good to you. Thanks, Pravesh -- Pravesh Sharma Software Engineer +91 9406461406 enterprisedb.com --00000000000061fdab0623f6aa07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Hackers,

We have been working on issue #8007. After our = analysis, we found that the length and scale of the argument's data typ= e are not stored in the database server, making it difficult to fetch. In t= he debugger, pgAdmin typecasts the provided value to its data type when cal= ling the function, which is causing the issue.

If we typecast the value to a character without specifying the length,= it is treated as a character (1) (character of length 1). For example, the= output of=C2=A0SELECT 'pgadmin', 'pgadmin&#= 39;::character;=C2=A0is different.

There are two solutions we can consider:

  1. Do not typecast if the data type is character.
  2. Typ= ecast to=C2=A0varchar=C2=A0when the = data type is character.
Please = provide your suggestions which solution looks good to you.

Thanks,
Pravesh
--


Pravesh Sharma

Software Engineer

+91 9406461406


enterprisedb.com

--00000000000061fdab0623f6aa07--