Malcontent null wrote:
> 
> >Anyway, so the larger class of problem is for the Sybase/M$ user who
> >relies on case insensitive queries (which *are* available in Postgres)

Maybe the right place to introduce case-insensitiveness would be in ODBC 
driver then ?

> If I may.
> MS Access for all of it's damnable faults is the single most popular
> database in the world. There are a whole slew of people who do nothing
> except access programming and make very good money at it. Postgres is
> a great candidate as a possible  back end database engine for access.
> This is a big possible application for postgres. To be usable for this
> purpose however it needs a few things.
> 1) Longer object names (I guess this is possible via a DEFINE)

How long should they be ?

> 2) Case insensitive queries.

Probably only the Access subset ("like", "order by", maybe even "=" ?)

> 3) Outer joins (coming soon!).
> 4) Maybe ADO drivers for the VB users of the world.

AFAIK MS moves fast and ADO will be soon (or is already) officially obsolete.

The technology du jour is XML.

> I don't know how important access integration is to the postgres
> community as a whole though.

Probably not a top priority. Oracle is much more often seen as the target.

---------------------
Hannu

Wed, 03 May 2000 13:58:40 +0300
Hannu Krosing <hannu@tm.ee>
Re: Why Not MySQL?
The Hermit Hacker wrote:
> 
> On Wed, 3 May 2000, Hannu Krosing wrote:
> 
> > Malcontent null wrote:
> > >
> > > >Anyway, so the larger class of problem is for the Sybase/M$ user who
> > > >relies on case insensitive queries (which *are* available in Postgres)
> >
> > Maybe the right place to introduce case-insensitiveness would be in ODBC
> > driver then ?
> >

...

> > > 2) Case insensitive queries.
> >
> > Probably only the Access subset ("like", "order by", maybe even "=" ?)
> 
> don't we have a 'lower()' function?
> 
> SELECT * FROM <table> WHERE field ~* 'this string' ORDER BY lower(field);?
> 
> or
> 
> SELECT * FROM <table> WHERE lower(field) = lower('StriNg');

That's what I meant by introducing pushing the case-insensitiveness into ODBC, 
so that the MS Access program can be made case-insensitive automatically by

A) rewriting the queries to use lower()

or

B) by using case-insensitive operators where possible.

----------------
Hannu

Wed, 03 May 2000 14:51:44 +0300
Hannu Krosing <hannu@tm.ee>
Re: Why Not MySQL?
On Wed, 3 May 2000, Hannu Krosing wrote:

> Malcontent null wrote:
> > 
> > >Anyway, so the larger class of problem is for the Sybase/M$ user who
> > >relies on case insensitive queries (which *are* available in Postgres)
> 
> Maybe the right place to introduce case-insensitiveness would be in ODBC 
> driver then ?
> 
> > If I may.
> > MS Access for all of it's damnable faults is the single most popular
> > database in the world. There are a whole slew of people who do nothing
> > except access programming and make very good money at it. Postgres is
> > a great candidate as a possible  back end database engine for access.
> > This is a big possible application for postgres. To be usable for this
> > purpose however it needs a few things.
> > 1) Longer object names (I guess this is possible via a DEFINE)
> 
> How long should they be ?
> 
> > 2) Case insensitive queries.
> 
> Probably only the Access subset ("like", "order by", maybe even "=" ?)

don't we have a 'lower()' function?

SELECT * FROM <table> WHERE field ~* 'this string' ORDER BY lower(field);?

or

SELECT * FROM <table> WHERE lower(field) = lower('StriNg');




Wed, 3 May 2000 09:27:16 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Why Not MySQL?
Hannu Krosing <hannu@tm.ee> writes:
> That's what I meant by introducing pushing the case-insensitiveness
> into ODBC,

I don't believe ODBC parses the query carefully enough to recognize
operators that would need to be altered to become case-insensitive.
I'm not even sure that it could do that --- does "WHERE f1 = f2"
need to be changed to "WHERE lower(f1) = lower(f2)"?  No way to know
that unless you know the datatypes of f1 and f2, which would mean
(a) a moderately complete SQL parser/analyzer and (b) a copy of the
system catalogs inside ODBC.  Doesn't sound like a promising avenue
of attack...

			regards, tom lane

Wed, 03 May 2000 11:51:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Why Not MySQL? 
Thomas Lockhart <lockhart@alumni.caltech.edu> wrote:
>
>clear that it may solve problems for a larger class of user than the
>one who managed to grow a M$ Access app to 300 tables and 1400 queries
>before deciding that Access might be a little light in performance to
>be suitable. But that's water under the bridge, eh?

Actually I did post twice I had hoped that I was being more clear the second time. As for growing the access database well sometimes apps take a life of their own. Database apps in general tend to be too critical to business to just scrap and rewrite so they just keep growing. 

>Anyway, so the larger class of problem is for the Sybase/M$ user who
>relies on case insensitive queries (which *are* available in Postgres)

If I may.
MS Access for all of it's damnable faults is the single most popular database in the world. There are a whole slew of people who do nothing except access programming and make very good money at it. Postgres is a great candidate as a possible  back end database engine for access.  This is a big possible application for postgres. To be usable for this purpose however it needs a few things.
1) Longer object names (I guess this is possible via a DEFINE)
2) Case insensitive queries.
3) Outer joins (coming soon!).
4) Maybe ADO drivers for the VB users of the world.
 
I don't know how important access integration is to the postgres community as a whole though.

>Of course the alternative is to just dive in and hack and slash at the
>backend code. Look in parser/gram.y and utils/adt/like.c for
>starters...

Thanks for the tip I'll start looking at this right away.

----------
Message To Spammers -- Game Over!  Get spam-free email at http://www.MsgTo.com

Wed May 03 02:37:10 EDT 2000
Malcontent null <malcontent@msgto.com>
Re: Why Not MySQL?