Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Marshall Spight <mspight_at_dnai.com>
Date: Sun, 24 Oct 2004 05:14:11 GMT
Message-ID: <DSGed.520856$8_6.132143_at_attbi_s04>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:4ivelc.ivc.ln_at_mercury.downsfam.net...
> Marshall Spight wrote:
>
> > "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> > news:jma9lc.ner.ln_at_mercury.downsfam.net...
> >>
> >> Code is recipes. They tell you what to do and you store them in a filing
> >> cabinet. Data is food, like flour and pies, you store them in the pantry
> >> and the refrigerator. When this distinction is not understood, you get
> >> paper in the fridge and flour in the filing cabinet.
> >
> > True, as far as it goes, but we can also consider code to be data, and
> > data to be code. Any bytecode system is a formal mechanism for specifying
> > code as data; the lambda calculus and Church numerals let us specify
> > data as code.
> >
> > I think there's not much value to considering data to be code, but I
> > do see value in viewing code as data, when appropriate.
>
> I would contend that it is never appropriate to consider SQL code to be
> data, it simply is not.

I respect your viewpoint however I disagree.

SQL code is most certainly data; it is at the very least a string, which I can manipulate in any of various ways and get back another string which might itself be valid SQL which I could then execute.

The fact that you said "never" makes your position untenable. If you say "mostly" I will agree with you, but "never" is way too strong.

> Code is data when you get down to certain levels, yes, like bytecode, and
> food is paper when you get down to carbon and nitrogen. But again I
> contend that when implementing database systems or meta-data systems there
> is only madness in confounding code and data.

Hmmm. So perhaps you meant "never when implementing database systems or meta-data systems."

> >> Or another example. I can do this:
> >>
> >> CREATE VIEW new_columns AS
> >> SELECT column_id FROM dd_columns
> >> WHERE column_id_existing IS NULL
> >>
> >> but I cannot do this:
> >>
> >> SELECT features FROM file:///BigBunchOfDDL.SQL
> >> WHERE Columns ARE Numeric
> >> AND columns HAVE Constraints
> >
> > Why not? The where clause at least is perfectly consistent with
> > querying the catalog. (I'm not sure I understand the FROM part.)
> >
>
> the FROM clause is a disk file full of SQL statements, or perhaps if you
> like Java or C#. You cannot query this information with SQL, because it is
> not in tables.

And what if it *was* in tables? Why shouldn't I be able to query it?

> Moreover, it is of a fundamentally different nature and
> does not even contain the same kind of information.

It would if it was in tables.

Marshall Received on Sun Oct 24 2004 - 07:14:11 CEST

Original text of this message