On Feb 9, 2009, at 7:47 AM, Marko Kreen <markokr@gmail.com> wrote:
> On 2/9/09, Andrew Dunstan <andrew@dunslane.net> wrote:
>> David Fetter wrote:
>>> On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
>>>> Now, if you want to argue that we should get rid of SET WITHOUT
>>>> OIDS
>>>> altogether,
>>>
>>> +1 for removing it altogether. Row OIDs are and ugly wart :P
>>
>> That might be true but I know of apps that use them. Having the
>> ability to
>> migrate those slowly by using SET WITHOUT OIDS is a Good Thing (tm).
>
> +1 for removal.
Why? What benefit do we get out of denying users this option?
>
> Also, whether the removal happens or not, I would suggest a setting
> that
> makes Postgres accept, but ignore default_with_oids / WITH OIDS
> settings.
>
> The problem is how to migrate apps that definitely do not use oids,
> in a situation where you have hundred of databases.
>
> Scanning all dbs and doing ALTER table would be option, if it would
> work 100% and would not touch data. Otherwise is cannot be used.
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.
> Trying to manually manipulate dump files which are filled with
> "SET default_with_oids" each time database is dumped/reloaded is also
> not an option.
>
> Currently the only sane path seems to patch Postgres to ignore the
> settings, but that does not seem very
...Robert