Re: Counting propositions

From: Laconic2 <laconic2_at_comcast.net>
Date: Mon, 14 Jun 2004 14:18:40 -0400
Message-ID: <CsadnRUdme46dlDdRVn-hA_at_comcast.com>


"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:GRlzc.26$kd5.79_at_news.oracle.com...

> > In particular, when does the wildcard get expanded to the list of all
the
> > columns? At compile time? at execution time?
> >
> > It makes a difference.
>
> Why does it make a difference? Exotic operators aside (e.g. Pivot by
> Microsoft), could you give an example, simple select-project-join
> preferrably?
>
>

Well, ok, but it probably won't help the discussion much.

If I remember my DEC Rdb/VMS from ten years ago right, (a big if), the translation of SQL was in two stages...

The first stage parsed the SQL and translated it into something called BLR (Binary Language Representation). This might be done by a precompiler or by an SQLMOD compiler. BLR was an intermidiate representation of the query, but not the plan for executing it. The second stage involved actually turning the BLR into an executable execution plan. This was done the first time the query was run.

If I remember right, the BLR did not contain any wildcards. Thus the original intent to mean "I want all the columns, what ever they are" is missing from the BLR. The BLR is data independent of the addition of new columns.

Now let's say that after you "compile" the source program, but before you execute it, along comes a DBA that has stopped taking his meds. In a manic mood, he adds a new column, fills in the value "0" for the existing rows, drops the primary key constraint, and adds a new primary key constraint that includes the new column. Why would he do that? I dunno!

Now we run the previously compiled query. It can deliver a different result from "select count(*)" ! Received on Mon Jun 14 2004 - 20:18:40 CEST

Original text of this message