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@Yahoo.com #