From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)hub(dot)org |
Cc: | chris(dot)bitmead(at)bigfoot(dot)com (Chris Bitmead) |
Subject: | Re: [HACKERS] pg_dump problem? |
Date: | 1999-05-07 14:18:53 |
Message-ID: | 13034.926086733@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"D'Arcy" "J.M." Cain <darcy(at)druid(dot)net> writes:
> 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.
Since COPY WITH OIDS works, I think there's no fundamental reason why
an INSERT couldn't specify a value for the OID field. Certainly,
persuading pg_dump to do this would be pretty trivial --- the only
question is whether the backend will accept the resulting script.
Unfortunately you say:
> I do know that the following crashed the backend.
> darcy=> insert into x (oid, n) values (1234567, 123.456);
This is definitely a bug --- it should either do it or give an
error message...
> Ultimately I think you need to get away from using OIDs in your top
> level applications.
I concur fully with this advice. I think it's OK to use an OID as
a working identifier for a record; for example, my apps do lots
of this:
SELECT oid,* FROM table WHERE ...;
UPDATE table SET ... WHERE oid = 12345;
But the OID will be forgotten at app shutdown. I never ever use an
OID as a key referred to by another database entry (I use serial columns
for unique keys). So, I don't have to worry about preserving OIDs
across database reloads.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-05-07 14:39:36 | Re: [HACKERS] Re:pg_dump barfs? |
Previous Message | Tom Lane | 1999-05-07 13:59:07 | Re: [HACKERS] Hashjoin status report |