On Thu, Feb 12, 2009 at 10:02 AM, Steve Crawford
<scrawford@pinpointresearch.com> wrote:
> Scott Marlowe wrote:
>>
>>> Close. It actually does a "SET default_with_oids = true;" (or false)
>>> prior
>>> to the CREATE TABLE statement. In any case, it does preserve the OID
>>> setting
>>> of the source database.
>>>
>>
>> So, I'd think it would be easier to just edit the backup than to muck
>> around in the 7.4 database.
>>
>
> The query to generate the drop-OID script runs in a fraction of a second and
> the drop-OID script itself takes a second or two and I'm done. The
> alternative requires running many gigs through sed (multiple times since I
> have to run preliminary tests).
I always dump schema and data separately when doing a migration like
this, so I don't have to do silly things like run many gigs through
sed to change one or two DDL lines. That way if something in my data
matches a change I'm making to my DDL, it won't get stomped on, or
vice versa. Also lets me work out schema issues separately and all
that.
OTOH, there are some issues with data that's got things like circular
references that can mess up a data / schema separate dump / restore.
There's lots of ways to skin this cat.