The Rel Forum

This release of Rel , an implementation of Date & Darwen's Tutorial D database language, improves the user interface, adds Infinity and NaN (Not a Number) to the recognised RATIONAL literals, and fixes some bugs. The following enhancements have been made: - DBrowser: The command-line now provides Ex...

I see the problem -- it's with the mechanism in the DBrowser front-end that tries to detect whether you've entered an expression or one or more statements. It's surprisingly complex and it can be fooled. In this case, it's being fooled into thinking you've entered an expression by the slashes '//', ...

I'll do some tests on this to see if I can find a workaround. I know EXTEND can expose a grammar ambiguity (I don't recall the specifics, but I know it does) and this is likely related to it.

Sorry for the slow response - I've been on holiday. This sounds like a bug in transaction handling; maybe the INSERT has written in a "write" transaction but is being read in a "read" transaction whilst the "write" transaction is still open and uncommitted. I've examined the code and can't see anyth...

It's an effect of making RENAME parallel. An expression like REL {TUP {X1 1}} RENAME {SUFFIX '1' AS '', X AS Y} now fails because for a parallel rename to work, the <old_name> of each <old_name> AS <new_name> pair must exist in the tuple/relation operand expression. By the way, apologies for the slo...

The trailing END IF, END CASE, or just END is needed to disambiguate the end of the conditional subexpression from the remainder of the expression.

I suppose it could be added as a Rel-specific extension, but I don't recall Tutorial D specifying NOT IN or equivalent.

This release of Rel , an implementation of Date & Darwen's Tutorial D database language, improves the user interface, fixes some bugs, adds support for outer joins, and significantly reduces the size of the Rel distribution whilst improving startup speed. The following enhancements have been made: -...

I've looked into this and have reminded myself why it works the way it does. There is a parsing ambiguity when using WITH (and similarly, TUPLE FROM, FROM, and TCLOSE) within WHERE, which I'll illustrate with an example. Given the following expression: WHERE WITH (p := x * 3): p > 2 AND x = 7 Does A...

I have fixed it.

The fix will be in the forthcoming update.

I've found a problem with resizing the Rel window when in "Rel" mode and using "Edit" to edit relvar contents. Whilst I haven't been able to precisely replicate the scrollbars disappearing, I suspect that problem and the resizing problem are related.

I'm working on fixing it.

Yes, I did later think of using parens, but our grammar does specify WHERE <bool exp> . There's a bit of oddness in the Rel grammar around how WHERE <bool exp> is handled -- particularly as ... WHERE <bool exp> ... can appear as a subexpression within a <bool exp> -- and how WITH is handled. In sho...

Try I'll make a note to look at operator precedence around WHERE and WITH.

I've experimented with this, and what happens on my Windows system (at least, the one I tested -- I'll try others later) is that the scroll bar appears when the relvar contents are displayed as it is by default, is still there when the relvar is edited (via 'Edit'), and when I select 'Show' to displ...

I've been able to duplicate this by selecting "Preferences | Command-line | Use an alternative output display ..." I presume you're using the alternative output display? I've made a note in my To Do list to fix this. As a short-term (though somewhat inconvenient) workaround, I've found I can make th...