Re: Using the catalogue

<amado.alves@xxxxxxxxxx> wrote in message
news:1132158320.612792.60310@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> > 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
--


.

Relevant Pages

  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... The only difference is "A1" (a run-time object of the type String) vs. A1 ...
    (comp.object)
  • Re: SQL
    ... The "expression engine" can be logically seperated from a relational ... query language, in theory they could without busting relational. ... They all are typed, as well as SQL. ... everything as pretty much a string. ...
    (comp.object)
  • Re: complex - split string in sql - need help
    ... SQL Server MVP ... procedural language they already know. ... In fact, even when they match an SQL data type, the conversion rules ... string comparisons are not case sensitive and the ...
    (microsoft.public.sqlserver.programming)
  • Re: complex - split string in sql - need help
    ... What I see is the developers using SQL as a file system for the ... procedural language they already know. ... In fact, even when they match an SQL data type, the conversion rules ... string comparisons are not case sensitive and the ...
    (microsoft.public.sqlserver.programming)
  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)