| 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: | Whole Thread | Raw Message | 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 |