> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> For input, I see no downside to just
> >> ignoring the incoming OIDs. For output, I can see three reasonable
> >> possibilities:
> >>
> >> A. Pretend WITH OIDS wasn't mentioned. This might seem to be
> >> "do the right thing", but a rather strong objection is that the
> >> app will not get back the data it was expecting.
> >>
> >> B. Return NULLs or 0s for the OIDs column.
> >>
> >> C. Raise an error and refuse to do the copy at all.
> >>
> >> C is probably the most conservative answer.
>
> > If we fail on load, we should fail on dump. Why not fail on COPY WITH
> > OIDS on a non-oid table?
>
> I'm confused --- I was proposing that we *not* fail on load. What's the
> point of failing on load?
I meant to say we should fail on dump _and_ load. If we don't we are
throwing away the oid's they are loading because though the table has no
oid column. Seems like something that should fail.
>
> >> How so? pg_description is broken anyway given that we don't enforce OID
> >> uniqueness across system catalogs. Also, in the future we could
>
> > We have a script to detect them and the oid counter it unique. In what
> > way do we not enforce it.
>
> In a running system, once the OID counter wraps around there's no
> guarantee that you won't have duplicate OIDs in different system
> tables. The only enforcement mechanism we have is the unique indexes,
> and those will only check per-table. However, that's fine --- it's
> as much as we need. For everything except pg_description, that is.
> Since pg_description currently makes an unchecked and uncheckable
> assumption of global uniqueness of OIDs, it's broken.
If you consider random table creation failures acceptible. In oid
wraparound, whether pg_description could point to two rows with the same
oid is the smallest part of our problem. I think the whole idea we can
run reliably with an oid wraparound is questionable.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
