Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS

>>  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.

>>  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.

...Robert