| From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Get constrrelid for fk constraints that lost it |
| Date: | 2002-09-30 15:14:14 |
| Message-ID: | 20020930080531.M80691-200000@megazone23.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
On Mon, 30 Sep 2002, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)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.
| Attachment | Content-Type | Size |
|---|---|---|
| constrrelid.patch | text/plain | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-30 15:24:20 | Re: Get constrrelid for fk constraints that lost it |
| Previous Message | Tom Lane | 2002-09-30 14:27:56 | Re: Get constrrelid for fk constraints that lost it |