Re: Get constrrelid for fk constraints that lost it
От | Stephan Szabo |
---|---|
Тема | Re: Get constrrelid for fk constraints that lost it |
Дата | |
Msg-id | 20020930080531.M80691-200000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Get constrrelid for fk constraints that lost it (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Get constrrelid for fk constraints that lost it
Re: Get constrrelid for fk constraints that lost it |
Список | pgsql-patches |
On Mon, 30 Sep 2002, Tom Lane wrote: > Stephan Szabo <sszabo@megazone23.bigpanda.com> writes: > > ... If the table doesn't exist or there > > aren't enough args to intuit a table name, it currently > > elog errors. Is that reasonable behavior, or should > > it be taking the constraint and letting it fail at > > runtime? > > I was inclined to think it should take the constraint and let the > failure occur at runtime. A NOTICE would be okay but not an ERROR. That's easy enough to do (changing a a false to true and an ERROR to NOTICE I believe) > (We can tweak the RI triggers to make the runtime failure message be > more helpful than "Relation 0 not found".) ISTM the point of having Are we mostly concerned about the case where it's 0 or all cases where the constrrelid relation doesn't open? > this hack is to allow old dump files to be loaded, and an ERROR would > get in the way of that. Yeah, I'd been thinking that they weren't in a transaction so an error would just not make the trigger, but that's not a safe assumption.
Вложения
В списке pgsql-patches по дате отправления: