Adriano dos Santos Fernandes wrote:

>> As soon as we give access via SQL to external metadata i have no problem
>> with view\relation\etc. Just not mix it into existing RDB$xxx and don't move it into
>> mega-database ;)
>>
>> What tables would query your system view ?
>>
>>
> Not real tables... Something like MON$ querying local system tables more
> remote data-sources.
> The data-source provider will need to have an API exposing this info.
>
> BTW, IMHO MON$ is much more like views than tables.
>

Why not use the architectural system tables? Then everything just works.

>
>>
>>
>>> AFAIR, Oracle stores only a timestamp of the original object, and the
>>> timestamp is also in the original database.
>>>
>>> If timestamp of object (in "client" and "server" databases of dblink)
>>> are different, the procedure/trigger are compiled again when executed,
>>> and if necessary invalidated.
>>>
>>>
>> This is depends if remote database have this info. Firebird, as you know,
>> didn't track such timestamps.
>>
> Yes, but external database can and will change.
>
> Having obsolete metadata copy of it doesn't do anything good.
>
>
>

In fact, it makes relatively little difference. A mechanism to refresh
is important, but that's about all. Table changes tend to toward new
fields and larger fields, all of which can be easily accommodated,
return at worst a truncation error.