Hi Brett,

>> /c/rSQL/Contacts/Name.s24
>>
>> which tells me that the "Contacts" table has a "string" column of 24
>> characters width named "Name".
>
> That's an innovative convention! Wasn't clear to me though what that
> particular file actually stored - all rows of a single column of data in 
> a fixed width form?

All rows of a single column of data (each row a seperate line), the width 
(in this example) being display width (mono-spaced character positions).

> If my comment was understatement, your question is the tip of an iceberg!
> :-)

Leading question I suppose ;)

> ...

Agree in full.

> *Perhaps allow some specific REBOL integration not available in the SQL
> parser options - eg. predicates expressed as REBOL expressions perhaps.

This is *the* biggie. If one goes down the SQL parser route then you have 
to try and map REBOL expressions to their SQL equivilants, eg:

        ;       LIKE
        like?: func [val string][
                either find/match/case/with val string "_%" [true][false]
        ]
        ;       NOT LIKE
        unlike?: func [val string][
                either find/match/case/with val string "_%" [false][true]
        ]

or accept REBOLisms that take away some of the advantages of a "pure" SQL 
implementation in the first place (familiarity and portability).

A well-designed REBOL SQL dialect enables you to leverage the underlying 
power of REBOL (much like VID does) without the translation / mapping 
overhead (ie. expressions are evaluated directly).

> It might be useful to have both, making the SQL parser subordinate (a
> helper) to the SQL dialect.

Not a bad idea in theory, although my impression after working with a 
large variety of RDBMS's over the years is that very few people use 
low-level API hooks when generic SQL equivilants are available. I guess 
familiarity and portability are the big ticket items to most folks (IMHO).

> It costs me nothing to throw out these ideas, actually building the stuff
> could be challenging :-)

It has been. Thanks for the stimulating discussion ;)


Regards,

        Ashley
-- 
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.

Reply via email to