Re: pg_dumpall and check constraints - Mailing list pgsql-general

From JanWieck@t-online.de (Jan Wieck)
Subject Re: pg_dumpall and check constraints
Date
Msg-id 200006301556.RAA09536@hot.jw.home
Whole thread Raw
In response to Re: pg_dumpall and check constraints  (Guillaume Perréal <perreal@lyon.cemagref.fr>)
Responses Re: pg_dumpall and check constraints  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-general
Guillaume Perréal wrote:
> >
> > OR
> >
> > 2. create a view:
> > create view "station_fields" as select * from information where fieldname = 'station.type';
> >
> > then use:
> >
> > FOREIGN KEY ( "type") references "station_fields" ( code),
>
> I tried : it doesn't work. It seems that view rows don't have OID, which are used in foreign key. (I deduce that from
theerror messages I've got  when I tried). 
>

    For  gods  sake  they  don't have.  And I'm uncertain that it
    should ever work.

    The reason is that an  FK  constraint  not  only  has  to  be
    checked  at  INSERT/UPDATE  time of the referencing table. It
    must  further  ensure  that  later   modifications   to   the
    referenced  table  don't  violate existing references. Now in
    the case of a view that is a join over 3 tables, we  setup  a
    multicolumn  FK constraint over columns coming from different
    base tables (or computed ones). How should a RESTRICT  or  ON
    DELETE CASCADE work in that scenario?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: disk backups
Next
From: Bruce Momjian
Date:
Subject: Re: Comments with embedded single quotes