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 itself, not my term. Calling it a statement modifier is much more appropriate than calling it a function, for example, the statement

VALIDTIME
SELECT * from S

must be used to retrieve the VALIDTIME column from S. By contrast the statement:

SELECT * from S

does not contain the VALIDTIME column, it is hidden from the usual selection mechanism, and the statement modifier VALIDTIME must be used to retrieve it. If VALIDTIME was allowed to be specified within the select list as an expression, that would be another matter, and I would be more inclined to agree with you, but this kind of statement-level modifier is truly bizarre. As I'm sure you can imagine, the situation only gets more complex when multiple tables and views are involved in the query. What if I want VALIDTIME from one table and TRANSACTIONTIME from another? Hardly an orthogonal extension to SQL.

Moreover, it is easy to imagine tables which contain multiple interval-valued columns, but the TSQL2 proposal makes no provision for this possibility, instead calling any column containing interval values "user-defined times" and does not allow the same types of operations to be performed on these columns. This is indeed a strange and restrictive way to achieve temporal support.

So I will stand by my claim that they are hidden columns and cannot be queried in the usual way :).

Regards,
Bryn Received on Tue Jul 20 2004 - 07:06:13 CEST