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 1sySb0-00042a-96 for pgadmin-hackers@arkaria.postgresql.org; Wed, 09 Oct 2024 09:03:03 +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 1sySa0-0000Kk-Cd for pgadmin-hackers@arkaria.postgresql.org; Wed, 09 Oct 2024 09:02:00 +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 1sySZz-0000Ka-2b for pgadmin-hackers@lists.postgresql.org; Wed, 09 Oct 2024 09:02:00 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sySZv-0008Bl-BQ for pgadmin-hackers@postgresql.org; Wed, 09 Oct 2024 09:01:58 +0000 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-5398b2f43b9so560145e87.1 for ; Wed, 09 Oct 2024 02:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1728464395; x=1729069195; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8KuUeQ2sQeaSEGqyZao8EsgmQKJzeKupp+XqMHHb/pU=; b=dKa2vDwRd+9qWHVF0Awfo2yhYiEFP9dX9PkOETVJ7tAO/0dDNfxt4k39+NFhEeU9SZ cw6YGtRn1olHMWv7PbnnAwYeMNsRgAcZ0iMrl2o9C+YU0PsNn5CDrd8ZjlPt/tTbmlPN bk/rm0c1eF4ZlIPgbDNK8f7VRD/fCs8ixtfnhU1H8PTzg9bwnCDuLkLk0db42XwUiwwO yZzj3QdUjg9ubHa6h80/CVSHB49iiRPSQJEK3g5tK/Y76+8KzfMR8d77tI+URQbeB0Zg 4W8sP4IoisZLMFlTiotcNbz/WJIDjAqiERdaLb2SjIAJc5TS7zVLoJ7VZGVS+SCvtpsM 9pHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728464395; x=1729069195; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8KuUeQ2sQeaSEGqyZao8EsgmQKJzeKupp+XqMHHb/pU=; b=ZJRAKUhdIaQMKyKcdce5K+wVSl8d9PAHcRN24apOiCM9kgi82BVGt9AkHFaR2WcNVG +qJtplM21hjaL1DisIhLrXpRqUUjibUFOojM52qDCGLnOSXbOsaC1mazFJAr9sRw/VhV X8OqjfnmJmnfY715Q9a8G9lzG79qvs9PYLHf9N0DLwVAoRquoNUkyU7r7T5t7vionzOl BwYF21fxiWEvXxeZ9bny573DmkGxU7o6AocNFYyni35IeY/lNiPOz/MIbrBZ4dZNYF9D Q27rqEe+JZtfRij8ifEjlNmoS6e9h8xDZBR9f/KT84ssZVe5KWM9AYsQ3ISlvObfRxGr LI1w== X-Gm-Message-State: AOJu0Ywh3vLR50sYcVRlyU+uzQB9F/9T01IgNGIx3xuHOfK/JC7GHLia +J5Z2/dZx76KHxvGeaAoQ7jVDR1L4ugdZ81hBEv+BCscuG3XM5MdC7TfDK6x9aQzLL0L9jPSHfQ 99dxj9hqypZM68GGU9ZJKso6wDtf2wmeJJP23/qJ3AcSUdCI= X-Google-Smtp-Source: AGHT+IFsRIv9CFwrq2STWgKuprEHvYf+eW8kDIjgwjCnaR+kZL9/+3SDwbhO3ksx8MXf/qpB6h5U+RmDtSN0u7oYS8E= X-Received: by 2002:a05:6512:31c3:b0:539:97cd:e7af with SMTP id 2adb3069b0e04-539bdae0d4dmr1847841e87.18.1728464394871; Wed, 09 Oct 2024 01:59:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 9 Oct 2024 09:59:43 +0100 Message-ID: Subject: Re: Require suggestion for issue #8007 To: Pravesh Sharma Cc: pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000437f070624077aa8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000437f070624077aa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 8 Oct 2024 at 16:30, Pravesh Sharma wrote: > Hi Dave, > > On Tue, Oct 8, 2024 at 6:34=E2=80=AFPM Dave Page wrot= e: > >> >> >> On Tue, 8 Oct 2024 at 13:56, Pravesh Sharma < >> pravesh.sharma@enterprisedb.com> wrote: >> >>> 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= 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. >>> >> >> Why not include the length in the cast? We know what the input string is= , >> so can't we just do the equivalent of: >> >> 'pgadmin'::character(7); >> > Just to confirm, this will be only for the character data type? > Yes, if that's the only type with which the issue is seen. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com --000000000000437f070624077aa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, 8 Oct 2024 at 16:30, Pravesh Sharma <pravesh.sharma@enterprised= b.com> wrote:
Hi=C2=A0Dave,

On Tue, Oct 8, 2024 at 6:34=E2=80=AFPM Dave Page <dpage@pgadmin.org&g= t; wrote:

<= /div>
O= n Tue, 8 Oct 2024 at 13:56, Pravesh Sharma <pravesh.sharma@enterprisedb.com> wrote:

Hi Hackers,

We have been workin= g on issue #8007. After our analysis, we found that the length a= nd scale of the argument's data type are not stored in the database ser= ver, making it difficult to fetch. In the debugger, pgAdmin typecasts the p= rovided value to its data type when calling the function, which is causing = the issue.

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

There are two solutions= we can consider:

  1. Do not typecast if = the data type is character.
  2. Typecast to=C2=A0var= char=C2=A0when the data type is character.
Please provide your suggestions which solut= ion looks good to you.

Why not include the length in the cast? We know what the input string= is, so can't we just do the equivalent of:

'pgadmin'::cha= racter(7);
Just to confirm, this = will be only for the character data type?

Yes, if that's the only type with which the issue is s= een.=C2=A0

--
<= /div> --000000000000437f070624077aa8--