AW: Why Not MySQL?

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

Responses

Browse pgsql-hackers by date

  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