Re: [SQL] RE: counting distinct rows on more than one column

[Jim Ballard]

If the fields are fixed length character type, then the simpler
concatenation should work.

Actually, the requirement is only that all but the final field be fixed
length.

And if they aren't fixed length, you can cast them to be such, as long as
you know the maximum length of the string values, as in the following where
that maximum is 20 and we are looking at 3 fields:

select count(distinct (cast(field1 as char(20)) || cast(field2 as char(20))
|| field3)) from ...

Jim Ballard

- Original Message -
From: "Jeff Eckermann" <[EMAIL PROTECTED]>
To: "'Dirk Lutzebaeck'" <[EMAIL PROTECTED]>; "Michael Fork"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 3:43 PM
Subject: [SQL] RE: counting distinct rows on more than one column


> I don't think this will necessarily work:
>
> field1 | field2
> aa |  ab
> a   |  aab
>
> These are two distinct rows, so should be counted as two.
> The proposed method would count them as one.
> You can get around this problem by doing:
> count (distinct (a || x || b))
> where x is some character not found in your data.
>
> > -Original Message-
> > From: Dirk Lutzebaeck [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 28, 2001 1:32 PM
> > To: Michael Fork
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: counting distinct rows on more than one column
> >
> > Michael Fork writes:
> >  > In 7.0.3, I believe the following would work:
> >  >
> >  > SELECT count(distinct(a || b)) FROM t;
> >
> > Great, this works! I don't quite get it why...
> >
> > Dirk
> >
> > ---(end of broadcast)---
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to [EMAIL PROTECTED] so that your
> > message can get through to the mailing list cleanly
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [SQL] Case Insensitive Queries

[Jim Ballard]

This is a good point - and it means that Postgres is not following the SQL Standard in 
this regard.  According to the standard, a scalar string function of a single string 
argument should return the same "type" of string as its input.  So 
upper() should return a fixed-char-field.  But it doesn't - it 
always returns a varchar that includes the trailing spaces from the space-padded fixed 
char argument.  And those trailing spaces are significant for the varchar comparison 
with the string literal.

It seems to me there are two ways to correct this behavior.  One is to have overloaded 
versions of the relevant string function that return the right types.  But, probably 
better, Postgres could support the notion of PAD SPACE or PAD OFF to control the 
behavior of string comparisons regardless of the particular types of the character 
fields involved.

Are ther plans to change this Postgres behavior?

Thanks,
Jim Ballard
Netezza Corp.

-- Original Message --
From: Mark <[EMAIL PROTECTED]>
Date: 29 May 2001 10:21:15 -0600

>We tried these but it didn't work.  However, that's because username is
>a bpchar and not a varchar, so its padded with blanks.  so we tried
>where lower(trim(username)) = 'test' and it works.  We'll change that
>column to varchar.  The real problem was in the datatype for username.
>
>Thanks,
>
>On 29 May 2001 12:35:53 -0400, ANDREW PERRIN wrote:
>> Try:
>> 
>> - The ILIKE operator, for example,
>> 
>> SELECT * FROM account WHERE username ILIKE "test";
>> 
>> - upper() or lower(), for example,
>> 
>> SELECT * FROM accont WHERE lower(username) = "test";
>> 
>> -
>>Andrew J. Perrin - Assistant Professor of Sociology
>> University of North Carolina, Chapel Hill
>> 269 Hamilton Hall CB#3210, Chapel Hill, NC 27599-3210 USA
>>[EMAIL PROTECTED] - http://www.unc.edu/~aperrin
>> 
>> On 29 May 2001, Mark wrote:
>> 
>> > Is it possible to execute a query using a where clause that allows case
>> > insensitive comparison between a field and text.
>> > 
>> > For example:
>> > 
>> > select * from account where username = 'test'
>> > 
>> > where username could be 'Test', which would be a match.  As is, this
>> > compare is case sensitive.
>> > 
>> > grep'd the source, but stricmp is only used for keywords and not actual
>> > column data.
>> > 
>> > Any help would be greatly appreciated.
>> > 
>> > Thanks,
>> > 
>> > Mark
>> > 
>> > 
>> > ---(end of broadcast)---
>> > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>> > 
>> 
>
>
>---(end of broadcast)---
>TIP 4: Don't 'kill -9' the postmaster
>

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly