The only thing that I'd like to add are the following 3 points:
1st POINT: I wished for global constants many times.
2nd POINT: I even have good use for a table constant, or virtual
column. E.g., a table that I would create like this:
CREATE TABLE Foo(
aVar INTEGER,
aConst INTEGER CONSTANT='15'
);
I know, this could be done with a VIEW, but I would like to use
it as follows:
ALTER TABLE Foo ADD
FOREIGN KEY(aVar, aConst) REFERENCES Bar(val1, val2);
see what I mean? The same could be done without the aConst
column if this were allowed:
ALTER TABLE Foo ADD
FOREIGN KEY(aVar, '15') REFERENCES Bar(val1, val2);
It's too bad that not at least the contant expression in the
foreign key reference is allowed. Until that is the case I need
to redundantly store the aConst in every tuple of the Foo table
(multiply this by 600 million and you begin to see my point :-).
3rd POINT: For global constants a constant function is a very
nice way of doing it, look again at Gregories 3rd suggestion:
Gregory Seidman wrote:
> 3. create a function for each type and use it in your queries
>
> CREATE FUNCTION EnumTypeSoftware() RETURNS int AS 'SELECT 1' LANGUAGE SQL
> with (isstrict);
>
> CREATE FUNCTION EnumTypeHardware() RETURNS int AS 'SELECT 2' LANGUAGE SQL
> with (isstrict);
>
> ... where KindID = EnumTypeSoftware() ...
This is so nice because (a) it can be done now. And (b) a
named variable is theoretically precisely this, a function
without arguments.
thanks,
-Gunther
--
Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
