On 2/9/09, David Fetter <david@fetter.org> wrote:
> On Mon, Feb 09, 2009 at 10:44:17AM -0500, Andrew Dunstan wrote:
> > Marko Kreen wrote:
> >> But now that I learned that ALTER TABLE WITHOUT OIDS either causes
> >> bugs or requires table rewrite, it turned from minor annoyance to
> >> big annoyance. So I'd like have a reasonable path for getting rid
> >> of them, which we don't have currently. Removing them completely
> >> is simplest path, but adding extra features to support it is
> >> another.
> >>
> >> If we are talking about adding a feature, then I like retargeting
> >> pg_dump --oids from data-only flag to apply to both data and
> >> schema. Yes, this is incompatible change, but the change affects
> >> feature we are discouraging anyway.
> >>
> >
> > How about a pg_dump flag that simply suppresses OIDs from the data
> > and schema?
>
>
> Defaults matter. How about one that *preserves* the aforementioned
> OIDs and have the default, if it finds OIDs, error out with a message
> like this:
>
> You have explicit OIDs in this database, which have been
> deprecated since 8.1. If despite this, you would like to preserve
> them, use the --oids option for pg_dump.
+1 for the warning.
If --oids is not given, do the check. I would argue that the check
should also see if there is index on the oid field, if not it's unusable
anyway. So mosts users who have oid columns because of migration
from older version, won't be bothered.
Or can the oid column be usable without index?
--
marko
