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 1qHA0r-0004XW-9q for pgsql-admin@arkaria.postgresql.org; Wed, 05 Jul 2023 21:26:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qHA0p-0002QL-IP for pgsql-admin@arkaria.postgresql.org; Wed, 05 Jul 2023 21:26:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHA0o-0002QC-T0 for pgsql-admin@lists.postgresql.org; Wed, 05 Jul 2023 21:26:11 +0000 Received: from mout-u-107.mailbox.org ([2001:67c:2050:101:465::107]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qHA0l-002EfP-1F for pgsql-admin@lists.postgresql.org; Wed, 05 Jul 2023 21:26:09 +0000 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4QxCPz3F1tz9sS1; Wed, 5 Jul 2023 23:25:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1688592359; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3Tcpb5e1Rsz1vSYkswNuHYdaJ0wHaD5HSB4neNmLT08=; b=NjIw7tMjDUZmBzqeuF1dAadHkSEvr5J5h2TrYvMoJApv+6wT51t+JRQwEVuqBi1fLeGU2y CYNN83V9U/ngW7ZUe/QUhvqDg3LJaVRyUg/65eaX3usbd5pcuJNLJ5Sb9WafTLvDj3QPhl IBdRlQwJpcX5SbczOHVJO27iw8CgOTzJtI09kFCj90uuus+U85S8n/xhHTPmmfSDMfNSiq DzArtKl0bnDPmuZmtKSPisky70aaMO1pzQA+Emv9mZKshuUbFe+hsAqYSCR+6sVy+0hIlk ZjEcbcP3M1t93FGIte9avK0eLKmYekWh9cEzVIX1N78fHBINeUO9lpUbFa4YuA== Date: Wed, 5 Jul 2023 23:25:59 +0200 (CEST) From: Erik Wienhold To: M Sarwar , "pgsql-admin@lists.postgresql.org" Message-ID: <1539000886.854641.1688592359041@office.mailbox.org> In-Reply-To: References: Subject: Re: SQL is fetching results BLANK checks but the data has no BLANKS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Rspamd-Queue-Id: 4QxCPz3F1tz9sS1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 05/07/2023 23:10 CEST M Sarwar wrote: > > Data in the database is uploaded using python. > > I have tried to test the same results by creating a sample table where I > inserted some sample data. In my sample test, I do not see any discrepanc= ies. > > ------------------------------ > From: M Sarwar > Sent: Wednesday, July 5, 2023 5:01 PM > To: pgsql-admin@lists.postgresql.org > Subject: SQL is fetching results BLANK checks but the data has no BLANKS > > SELECT TEST_NUMBER > FROM BRONX.TEST_TEST_DETAILS_ALL_MCM > WHERE LEFT(TEST_DESCRIPTION, 1) =3D ' ' > ; > The above SQL is fetching lot of data but when I take closer look at the = data > in the table TEST_TEST_DETAILS_ALL_MCM, I see no prefixed BLANKS in the c= olumn > TEST_DESCRIPTION. > > test_description character varying(50) COLLATE pg_catalog."default", -- T= EST_DESCRIPTION, type > > What could be the reason here for fetching the data when I do not have th= e > data which has prefixes of BLANK , =E2=80=98 =E2=80=98. Is there a functional index on left(test_description, 1) ? My guess is tha= t the index is corrupted. This can be fixed with REINDEX. -- Erik