Re: pg_dumpall and check constraints
От | JanWieck@t-online.de (Jan Wieck) |
---|---|
Тема | Re: pg_dumpall and check constraints |
Дата | |
Msg-id | 200006301556.RAA09536@hot.jw.home обсуждение исходный текст |
Ответ на | Re: pg_dumpall and check constraints (Guillaume Perréal <perreal@lyon.cemagref.fr>) |
Ответы |
Re: pg_dumpall and check constraints
|
Список | 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 по дате отправления: