Philip Warner wrote:
> At 11:33 1/07/00 +0200, Jan Wieck wrote:
> >
> > Was late for me too, and maybe the answer was too lazy. So
> > let me give you an example of what I meant:
> >
>
> About 5 mins after I hit the send button on my last message I realized the
> error in my ways (again). There are probably limitations one could place on
> such views, but the effort would be high, and the rewards low.
>
> But, at the risk of yet another ill conceived plan being laid bare, and to
> satisfy the original posters requirements, could FOREIGN KEY be extended to
> allow:
>
> FOREIGN KEY({<field>|<literal>}...) references <table>({<field>}...)
>
> This seems like a very convenient feature...if it's not too hard.
The only reason why someone wants to put a <literal> into the
foreign key seems to me as a referencing table identifier. So
that multiple referencing tables would all have their own
possible values in one big primary key table.
First this is already possible by adding such a table
identifier field to the referencing tables and having a
BEFORE trigger enforcing the correct value.
Second it's allways good practice to keep things separate
that are separate.
Thus I don't see the need to add non SQL standard features to
FOREIGN KEY.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
