Re: Using the catalogue

From: David Portas <>
Date: Wed, 16 Nov 2005 20:44:55 -0000
Message-ID: <>

<> wrote in message
>> > all triplets (field name, value, relation), from any relation, such
>> > that field name is in {Name, Designation}, field type is String, and
>> > field value = "King"
>> It seems that two relational operators would be sufficient. One to
>> return the catalogue and one to "evaluate" a union based on some
>> restriction of a catalogue relvar. A D language assumes an open ended
>> set of user-defined operators and types so I don't see why this should
>> be forbidden in Tutorial D for example.
>> SQL has the catalogue but the "evaluation" part isn't in standard SQL
>> AFAIK. However, all SQL products that I'm familiar with implement some
>> form of dynamic SQL as an extension - that should be up to the task.
> I see.
> And the easiest way I envisage to endow a traditional language with the
> capability is to extend the language with two things
> (1) means to create strings by concatenating any part of the result of
> any query
> (2) an interpreter function
> I think many SQLs already have (1), and as for (2) clearly the DBMS has
> an SQL interpreter inside so it is just a matter of making it available
> in the language (as some programming languages do e.g. Clipper,
> Snobol).
> Ok, so I guess my question is not one of possible vs. impossible
> anymore but of "how well"---which is a very much harder question to
> answer altogether, so let me start again:
> (a) is this an interesting problem at all?
> (b) does it occur in the real world?
> Thanks a lot.
> --Marius

*Dynamic* queries certainly occur in the real world. Decision support systems and searches that have optional parameters are two applications that often make extensive use of dynamic queries. It is also certain that there are important problems around the implementation of dynamically coded operations, their security, reliability and optimization. Security because user-supplied data that drives dynamic code may allow a user to execute arbitrary code in the database; Reliability because of the formidable difficulty of testing dynamic code for correctness; Optimization because that has to occur to some extent at runtime rather than design-time.

David Portas
SQL Server MVP
Received on Wed Nov 16 2005 - 21:44:55 CET

Original text of this message