Re: A question for Mr. Celko

Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:<pan.2004.07.19.22.43.38.416358_at_REMOVETHIS.pandora.be>...
> Like I said, you *can* query them. :-) And calling the functions VALIDTIME
> and TRANSACTIONTIME statement modifiers seems to me like stretching the
> concept beyond its usual meaning.

The term statement modifiers is from the TSQL2 proposal, it's not my term. At any rate it's more applicable than function, they apply at the statement level, not at the expression level. For example, the statement:

VALIDTIME
SELECT * from T

must be used to retrieve the VALIDTIME column, it is not visible within the usual selection mechanism. By contrast, the statement:

SELECT * from T

does not have the VALIDTIME column, it is hidden, even though the table actually has a VALIDTIME implicit column (TSQL2 terminology). If the VALIDTIME and TRANSACTIONTIME keywords were available as expressions within the select expression, I would be much more inclined to agree with you, but they are not. As I'm sure you can imagine, the problem only gets more complex when multiple tables are involved. And what happens when I want VALIDTIME from one table and TRANSACTIONTIME from another? Hardly an orthogonal mechanism for introducing temporal support into SQL.

Moreover, it is easy to imagine tables with multiple interval-valued columns, but the TSQL2 proposal makes no provisions for this possibility, instead calling all columns with time values "user-defined times" and does not allow the same operations on these columns. This is extremely disturbing, if not downright bizarre.

Therefore I stand by my claim that the TSQL2 proposals involve hidden columns that cannot be queried in the usual way. Indeed I find the entire proposal contrived and convoluted. This is in sharp contrast to the elegant solutions proposed in Temporal Data and the Relational Model.

Regards,
Bryn Received on Tue Jul 20 2004 - 07:40:09 CEST