Re: [HACKERS] pg_dump problem?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_dump problem? |
Дата | |
Msg-id | 13034.926086733@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_dump problem? ("D'Arcy" "J.M." Cain <darcy@druid.net>) |
Ответы |
Re: [HACKERS] pg_dump problem?
|
Список | pgsql-hackers |
"D'Arcy" "J.M." Cain <darcy@druid.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
В списке pgsql-hackers по дате отправления: