On 2/9/09, Robert Haas <robertmhaas@gmail.com> wrote:
> >> Why? What benefit do we get out of denying users this option?
> >
> > Why should we continue to support historical special case? It is not
> > a feature that adds anything to user experience with Postgres.
> >
> > Anyway, that was my vote only. If there are developers interested
> > in supporting oids feel free to do so.
> >
> > 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.
>
>
> Well, see Tom's point upthread: OIDs are extensively used for system
> tables, and are not going away. So this is a pipe dream. In the
> meantime, ALTER TABLE WITHOUT OIDS is (at least for some people) an
> easier migration path than dump+reload.
Sorry, I was talking only about oids in user tables.
> >> That might be true in your environment, but is certainly not true in
> >> general. We have many DDL commands that require full-table rewrites, and
> >> they are FAR from useless.
> >
> > Compared to not having the DDL commands or having DDL commands that
> > do not rewrite the tables? ;)
>
>
> Not having them, of course.
>
> If we remove ALTER TABLE WITHOUT OIDS, it's going to encourage people
> to do stuff like this:
>
> CREATE TABLE blah_without_oids AS SELECT * FROM blah;
> ALTER TABLE blah ...
> ALTER TABLE blah ...
> -- move foreign keys, constraints, etc.
> DROP TABLE blah;
> ALTER TABLE blah_without_oids RENAME TO blah;
>
> ...or else dump+reload. ISTM that if anything that's going to
> encourage people to keep the OIDs in there because it's too much work
> to get rid of them.
By "removing" I mean that in version 8.6 you simply cannot create user
table with oids. Thus no need to get rid of them.
If we keep the possibility to create tables with oids, obviously
the ALTER, etc command must also be kept.
--
marko
