Martijn Tonies wrote:

>>I think that won't work in Classic since processes may
>>have requests that are compiled but not active. They
>>must be notified so they can recompile their requests
>>to include the new constraint. My model would be an
>>abstract existence lock which is acquired when a table is
>>referenced in a compiled request and released when the
>>request is released. The index header page serves that
>>purpose for indexes. A similar lock could be used on
>>procedures to insure that changes to them are propagated
>>as well.
>>
>>
>
>It might be me ... but: what changes need to be propagated
>to a procedure or compiled request?
>
>New indices? Why?
>
>
>

New indices need to be propogated in classic so updates performed in
other processes know to update the index.

In the original design, there was no need to propogate relation
changes. If a process saw a new format version, it simply fetched it.
Blr doesn't allow an analog of "select *", so it made no difference to
any database process whether the logical metadata was current or not,
though it might check the metadata for an unknown field before returning
an error.

The SQL world is different. The addition of a field or a change of a
database does affect SQL semantics (getting the same answer to "SELECT
*" from all database processes is desirable). The issue can be ignored
in superserver, but Vulcan, at least, has a universal engine that must
address the problem.


[Non-text portions of this message have been removed]