Thread

Re: Why Not MySQL?

Hannu Krosing <hannu@tm.ee> — 2000-05-03T10:58:40Z

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

Re: Why Not MySQL?

Hannu Krosing <hannu@tm.ee> — 2000-05-03T11:51:44Z

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

Re: Why Not MySQL?

Marc G. Fournier <scrappy@hub.org> — 2000-05-03T12:27:16Z

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');

Re: Why Not MySQL?

Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-03T15:51:27Z

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

Re: Why Not MySQL?

Malcontent null <malcontent@msgto.com> — 2026-05-03T22:37:10Z

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