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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
Date: 2009-02-09 14:09:11
Message-ID: 0ED8E6F0-E5F7-4B02-83EA-FEBE0B29F21B@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Feb 9, 2009, at 7:47 AM, Marko Kreen <markokr(at)gmail(dot)com> wrote:

> On 2/9/09, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2009-02-09 14:16:48 Re: Synch Replication
Previous Message Mihai Criveti 2009-02-09 14:06:50 Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650)