Re: The same result for with SPACE and without SPACE

From: M Sarwar <sarwarmd02(at)outlook(dot)com>
To: Paul Smith* <paul(at)pscs(dot)co(dot)uk>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: The same result for with SPACE and without SPACE
Date: 2023-06-15 17:26:28
Message-ID: DM4PR19MB597818A20E53C97BDB03AE8BD35BA@DM4PR19MB5978.namprd19.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-advocacy

I guess behaviour is the same in Oracle as well.
Thanks,
Sarwar

________________________________
From: Paul Smith* <paul(at)pscs(dot)co(dot)uk>
Sent: Thursday, June 15, 2023 11:48 AM
To: pgsql-admin(at)lists(dot)postgresql(dot)org <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: The same result for with SPACE and without SPACE

On 15/06/2023 16:21, Wetmore, Matthew (CTR) wrote:

Before you kick me out of the group, can you please explain.

I thought the orig issue was that purposefully spaces/whitespace are being ignored (or not ignored.) in the select. Maybe there was an email in the middle that I missed

create table matt_test (c1 int)

insert into matt_test values ('123')

insert into matt_test values (' 123')

insert into matt_test values ('123 ')

select c1 from matt_test where c1 = '123'

-- all 3 rows returned.

Is it expected behavior that all 3 rows would be returned (because the space isn’t an INT?)

Yes, that's totally expected behaviour. The "problem" is that it's pretty much obvious behaviour as well.

Your table is defined to store numbers not text.

So, when you do

insert into matt_test values ('123'); -- with any combination of leading/trailing spaces

Postgresql converts it to

insert into matt_test values(123)

So, all three inserts you did are actually the same, and all store the *NUMBER* 123 in the table. Spaces are not part of the number, so are not stored

When you make the table store 'TEXT' or VARCHAR fields, then spaces ARE relevant for that type, so the data stored is different. For CHAR fields, they are space-padded or truncated as necessary to be the defined field size.

This is all pretty much basic SQL behaviour. Any correctly implemented SQL database server will behave exactly the same.

Paul

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message M Sarwar 2023-06-15 17:43:51 Re: The same result for with SPACE and without SPACE
Previous Message M Sarwar 2023-06-15 17:16:53 Re: The same result for with SPACE and without SPACE

Browse pgsql-advocacy by date

  From Date Subject
Next Message M Sarwar 2023-06-15 17:43:51 Re: The same result for with SPACE and without SPACE
Previous Message M Sarwar 2023-06-15 17:16:53 Re: The same result for with SPACE and without SPACE