Mailing List Archive


Back to the month index Back to the list index
Ross Mack (rossmack@gui.com.au)
Wed, 15 Jan 1997 13:56:19 +1100 

Message-Id: <199701150256.NAA27672@budgie.gui.com.au>
From: "Ross Mack" <rossmack@gui.com.au>
Subject: Re: [mSQL] 2.0 - can it cache results?
Date: Wed, 15 Jan 1997 13:56:19 +1100

> I am not sure what the ANSI spec says on this. Does the table have to
> exist before you can select into it, or does select into create the
table?
> If the latter, the select into clause itself should check if the table
> already exists before starting to the select.
SELECT INTO creates the table from scratch, no CREATE TABLE is required. In
fact I believe it is also standard to DROP any existing table before
creating a new table. Certainly checking if it already exists is
intelligent. If so, you may not need to bother to recreate it...

> of a CERT advisory. Client applications need to handle the tables
> intelligently.
Yes, the server performs it's job of executing the SQL that client
applications ask of it. It shouldn't be the job of Bambi to hold the hand
of those db users/abusers that get themselves into such a mess. Just
implementing a good SQL engine is work enough. If someone wants to
implement a non-normalised database structure, that is allowed. So should
doing other silly things.

> becomes a query cache. I will happily manage my query cache myself. I
will
> set a limit of say 100 tables and whenever a new one is generated, I
delete
> the oldest, or least used, or whatever other logic I decide to use.
Yes, yes. Exactly. We currently use a similar scheme when caching results
from PostGres (as it is SOOO slow) using a berkley DB of SELECT statements
and text files of result sets. For once let the programmer do some work
implementing appropriate logic of their own. Too many tools these days let
the programmer get away with too much, I don't think that approach is
necessary or advisable.
Hmmm. That'll do for now.
        - Ross
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!