Thus spake Chris Bitmead
>
> Am I right in saying that the -o and -D arguments to pg_dump cannot work
> together? Any chance of this getting fixed?
I suspect that the problem is that you can't insert an OID into the
system using standard SQL statements but I'm not sure about that. I
do know that the following crashed the backend.
darcy=> insert into x (oid, n) values (1234567, 123.456);
> Otherwise is there any other way of deleting a column from a table
> whilst retaining oids? In general there seems there are problems with
> various scheme changes that you may want to do if you need to retain
> oids. Various SELECT INTO options don't work any more unless there is
> some way to set the oid in conjunction with named fields (like the -D
> option).
Ultimately I think you need to get away from using OIDs in your top
level applications. Depending on them causes these kinds of problems
and moves you farther from standard SQL in your app. Use of the OID
(IMNSHO) should be limited to temporary tracking of rows and even then
it should be in middle level code, not the top level application. I
offer the use of OIDs in pg.py in the Python interface as an example
of middle code.
I suggest that you replace the use of OID in your database with a serial
type primary key. That allows you to dump and reload without losing
the information and it performs the same function as OID in your code.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.