Re: pg_dumpall and check constraints

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(at)Yahoo(dot)com #