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
Mark <[EMAIL PROTECTED]> writes:
> Even the postgresql documentation asserts something similar to this:
You're reading obsolete documentation. There is no such assertion
(as far as I can find, anyway) in the 7.1 documentation. The speed
advantage of bpchar --- which was always extremely margina
On 30 May 2001 12:53:22 -0400, Tom Lane wrote:
>
> You are operating under misinformation about what's efficient or not.
> There are no performance penalties that I know of for varchar ... if
> anything, bpchar is the less efficient choice, at least in Postgres.
> The extra I/O costs for those
On 30 May 2001, Mark wrote:
> On 30 May 2001 11:16:35 -0700, Stephan Szabo wrote:
> > On Wed, 30 May 2001, Tom Lane wrote:
> >
> > > Mark <[EMAIL PROTECTED]> writes:
> > > > It appears that the behavior of a bpchar compare with a string literal
> > > > is not implicitly trimming the bpchar befo
On 30 May 2001 11:16:35 -0700, Stephan Szabo wrote:
> On Wed, 30 May 2001, Tom Lane wrote:
>
> > Mark <[EMAIL PROTECTED]> writes:
> > > It appears that the behavior of a bpchar compare with a string literal
> > > is not implicitly trimming the bpchar before the compare, which IMHO is
> > > incorr
On Wed, 30 May 2001, Tom Lane wrote:
> Mark <[EMAIL PROTECTED]> writes:
> > It appears that the behavior of a bpchar compare with a string literal
> > is not implicitly trimming the bpchar before the compare, which IMHO is
> > incorrect behavior. Is my opinion valid?
>
> regression=# create tab
Mark <[EMAIL PROTECTED]> writes:
> It appears that the behavior of a bpchar compare with a string literal
> is not implicitly trimming the bpchar before the compare, which IMHO is
> incorrect behavior. Is my opinion valid?
regression=# create table foo (f1 char(20));
CREATE
regression=# insert i
I use a few of them, and in my opinion there is a distinct group of
characters at last in the 8859-1 character set which have a lower and
upper case instance. The ranges are 0xC0 to 0xDD for upper case and 0xE0
to 0xFD for upper (with the exception of 0xD0, 0xD7, 0xF0, and 0xF7).
I haven't examin
It appears that the behavior of a bpchar compare with a string literal
is not implicitly trimming the bpchar before the compare, which IMHO is
incorrect behavior. Is my opinion valid? If so, how difficult of a fix
would this be in terms of time and effort? Should I submit a bug report
to anothe
It appears that the behavior of a bpchar compare with a string literal
is not implicitly trimming the bpchar before the compare, which IMHO is
incorrect behavior. Is my opinion valid? If so, how difficult of a fix
would this be in terms of time and effort? Should I submit a bug report
to anothe
It appears that the behavior of a bpchar compare with a string literal
is not implicitly trimming the bpchar before the compare, which IMHO is
incorrect behavior. Is my opinion valid? If so, how difficult of a fix
would this be in terms of time and effort? Should I submit a bug report
to anothe
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> If upper() and lower() operate on characters in 8859-1 and other character
> sets when the appropriate locale is set, then a difference in the behavior
> of upper() and lower() would seem like a bug.
Au contraire ... upper() and lower() are not sy
Can you please explain in little more detail? I am curious.
I haven't noticed any discussion about upper() being different from
lower() when it comes to such comparisons. As far as I know, upper()
and lower() only operate on ascii characters a-z. If you are using the
default locale, neither func
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'
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 M
Mark writes:
> Is it possible to execute a query using a where clause that allows case
> insensitive comparison between a field and text.
select * from account where upper(username) = upper('test')
(Upper used because, as has been remarked on this list and in other places,
folding from richer ch
> 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
select * from account where lower(username) = lower('test');
Troy
>
> 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
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,
19 matches
Mail list logo
