From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Malcontent null <malcontent(at)msgto(dot)com> |
Cc: | Don Baccus <dhogaza(at)pacifier(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why Not MySQL? |
Date: | 2000-05-03 15:12:21 |
Message-ID: | 7573.957366741@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Malcontent null <malcontent(at)msgto(dot)com> writes:
> "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."
Well, it'd certainly be easy enough to make a case-insensitive set of
text comparison functions and LIKE comparator (sounds like you already
found out where they live, so go to it). The $64 question is exactly
when where and how to invoke them. For your immediate purpose I suppose
you can just alter the standard operators, and thus produce a server
that can do nothing *but* case-insensitive text comparisons. That will
certainly not be acceptable as a general-usage answer, however.
There has been a good deal of talk about supporting more of SQL92's
national-character and collation features in future releases. What
might ultimately happen is that we offer a case-insensitive collation
mode that could be assigned to particular text columns, or even
made the default for a whole database. Not sure how far down the road
that is.
In the meantime, there's no shame in running a locally-hacked server.
That's one of the things that open source is for, after all ;-)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2000-05-03 15:17:56 | Re: 7.0RC2 compile error ! |
Previous Message | The Hermit Hacker | 2000-05-03 14:48:03 | Re: Corruption (Was: Re: Why Not MySQL?) |