[Rets-dev] RETS2 Workgroup Meeting Tuesday 3/14 2PM EST - RQL Query Language

[Dave Scott]

retsdev at develest.com wrote:
 >What is not wise is taking data off the wire from a third party and
 >handing it to your database.
 >
 >The primary goal of RQL, as I understand it, is to make the process
 >of generating RETS queries more comfortable to software developers.

 >If you really want to let someone search for:
 >
 >RQL=(field%3d'value')%3bdrop+table+property_table
 >
 >then by all means take whatever comes off the wire and feed it to your
 >database. :)


I make no claim in my message that RQL should let us do away with any  
intermediate processing of a RETS request.  Nonetheless, if I set the  
security on my view correctly, I'm not worried about someone trying  
to smuggle a "drop table" command into a query.



In any case, your response misses my main point:  If the RETS query  
language is going to move in the direction of SQL,  the move should  
be made in a way that allows us to take full advantage of existing  
SQL-based technology (not just the databases themselves, but  
libraries, utilities, etc.)  I understand the need to subset SQL, but  
extending SQL should be avoided if possible.  In the case of the "ALL  
IN" operator, it is possible; there are SQL equivalents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20060314/2607f807/attachment.html