Actual, Mark, calling inheritance IS a bad idea. Inheritance conjures
the image of changes in the master source being automatically propagated
to the children. This is not what your have described.

Isn't your INHERIT parameter, nothing more that a GBAK of the metadata
only, which is already available?

I would like to suggest that the discussion of UDF definitions (and
related topics) might be significantly minimized if the base engine
natively supported a wider range of functions (which are currently 99%
of most users UDF requirements). The discussion about master
definition/inheritance/what-have-you would almost be a non-event. This
is where, I very strongly believe, the engine/efforts should be
directed.

(With respect, to those who would argue that adding these functions to
the engine would increase the IB footprint, I want to point out that my
on UDF library is only 360K in size - this is NOTHING!)


Sean

-----Original Message-----
From: Mark Shapiro [mailto:Mark.Shapiro@...]
Sent: Friday, May 05, 2000 9:30 AM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Database names: Hair trigger

>I didn't call it inheritance, I used an analogy. In any case I was

thinking

>of something a little more integrated. It seems to me that placing this
>functionality in isql is limited as a complete solution. What if I have

a

>system that uses another method of creating a database (like with

IBPerl?)

>and I want to make sure that all database creations are given the same
>default functionality?

Actually, calling it inheritance isn't necessarily a bad idea. When you
go
to create a database, there could be parameters to the CREATE DATABASE
call,
such as:
INHERIT mydatabase.gdb
which would tell CREATE DATABASE to use mydatabase.gdb as a base, and
maybe
META-ONLY
which would tell INHERIT only to inherit metadata

In this way you could inherit not only UDFs, but also table structures.




To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com