Mailing List Archive


Back to the month index Back to the list index
rasmus@mail1.bellglobal.com
Tue, 14 Jan 1997 11:19:48 -0500 (EST) 

From: rasmus@mail1.bellglobal.com
Date: Tue, 14 Jan 1997 11:19:48 -0500 (EST)
Subject: Re: [mSQL] 2.0 - can it cache results?
Message-Id: <ML-2.3.853258788.4005.rasmus@inet-dev>

> But then that gives the worst of both worlds. The applications have to
> work out a way to try to generate a unique name for the table (as there
> may be many people running the same query at the same time). You can't
> just chuck a PID on the end as the app's could be running on various
> machines client/server.

Well, if CREATE TABLE returned an error, I don't see this as being a big
problem. With a pid, a random number and a timestamp, the chances of
getting duplicates decrease dramatically. And even if you do get a duplicate,
you just catch the error and generate a new table name and try again. That
assumes of course that you do a "CREATE TABLE" before the "SELECT INTO".
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.

> You also still get the problem of someone htting a certain web page a few
> dozen times and filling up your disk space. Yet another denial of
> service attack in the making. I'd hate to see a CERT advisory come out
> about mSQL! :)

The CERT advisory would certainly not be mSQL related in this case. That is
like saying that a CERT advisory could be issued about Unix file systems
because someone writes a script to append hits to a file continuously.
"select into" is standard ANSI SQL, its implementation would never be a topic
of a CERT advisory. Client applications need to handle the tables
intelligently.

Personally the way I would use the tables would be to base the name of the
table on the actual select clause that created it. It then in effect
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.

-Rasmus
--------------------------------------------------------------------------
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!