From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Cc: | "'Malcontent null'" <malcontent(at)msgto(dot)com> |
Subject: | AW: Why Not MySQL? |
Date: | 2000-05-03 08:58:51 |
Message-ID: | 219F68D65015D011A8E000006F8590C604AF7D6A@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "In a nutshell I want to use postgres as a back end to an access
> database. This means that all collation done by postgres musht be case
> insensitive including like clauses."
>
> I left the all the spelling mistakes in place :)
Could a national char implementation that is case insensitive be a solution
here ?
Meaning: is it as simple as setting LC_COLLATE to another value and
configuring
--enable-locale ?
How far is Thomas with the nchar nvarchar types ?
I think national char and national char varying are the correct datatypes
for
such behavior. Although I think the = operator is still case sensitive for
that datatype.
Replacing = or like for the char and varchar or text datatypes is probably
not possible,
because it is used internally, but for nchar ... it should be.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-05-03 09:00:17 | Re: RE: [PATCHES] relation filename patch |
Previous Message | Peter Mount | 2000-05-03 06:58:53 | RE: Re: [GENERAL] postgresql7.0 jdbc driver |