Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 - Mailing list pgsql-hackers

No, people can confuse writing, but it makes a computer.
Unfortunately, I have not found developer this database, but I understand the logic was:
plob - primary key (lob ~ BLOB)
rlob - reference key (lob ~ BLOB)
Maybe if I describe the task, this part of the database, the problem is clear.
We need to maintain external documents (binary scans, per page).
Therefore, there is a table to store the titles and a table to store binary data.
To make it more comfortable I replaced all Russian words translated words.

This a table for headers store.

-- Table: "VersionOfTheExternalDocument$Document"
-- DROP TABLE "VersionOfTheExternalDocument$Document";

CREATE TABLE "VersionOfTheExternalDocument$Document"
( "@File" integer NOT NULL DEFAULT
nextval((pg_get_serial_sequence('"public"."VersionOfTheExternalDocument$Document"'::text,'@File'::text))::regclass),
"GUID"uuid, "DataTime" timestamp without time zone DEFAULT (now())::timestamp without time zone, "Name" character
varying,"Size" integer, CONSTRAINT "VersionOfTheExternalDocument$Document_pkey" PRIMARY KEY ("@File") 
)
WITH ( OIDS=FALSE
);
ALTER TABLE "VersionOfTheExternalDocument$Document" OWNER TO postgres;
GRANT ALL ON TABLE "VersionOfTheExternalDocument$Document" TO postgres;
GRANT SELECT ON TABLE "VersionOfTheExternalDocument$Document" TO view_user;

-- Index: "iVersionOfTheExternalDocument$Document-blb_header"
-- DROP INDEX "iVersionOfTheExternalDocument$Document-blb_header";

CREATE INDEX "iVersionOfTheExternalDocument$Document-blb_header" ON "VersionOfTheExternalDocument$Document" USING btree
("GUID","@Файл", "ДатаВремя") WHERE "GUID" IS NOT NULL; 
---------------------------------------------------------------
And this for data.

-- Table: "lob.VersionOfTheExternalDocument$Document"
-- DROP TABLE "lob.VersionOfTheExternalDocument$Document";
CREATE TABLE "lob.VersionOfTheExternalDocument$Document"
( "@File" integer NOT NULL, "Page" integer NOT NULL, "Data" bytea, CONSTRAINT
"lob.VersionOfTheExternalDocument$Document_pkey"PRIMARY KEY ("@File", "Page"), CONSTRAINT
"rlob.VersionOfTheExternalDocument$Document-@File"FOREIGN KEY ("@File")     REFERENCES
"VersionOfTheExternalDocument$Document"("@File") MATCH SIMPLE     ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE
INITIALLYIMMEDIATE 
)
WITH ( OIDS=FALSE
);
ALTER TABLE "lob.VersionOfTheExternalDocument$Document" OWNER TO postgres;
GRANT ALL ON TABLE "lob.VersionOfTheExternalDocument$Document" TO postgres;
GRANT SELECT ON TABLE "lob.VersionOfTheExternalDocument$Document" TO view_user;








20.12.2012, 07:12, "Bruce Momjian" <bruce@momjian.us>:
> On Wed, Dec 19, 2012 at 10:35:11PM -0500, Bruce Momjian wrote:
>
>>>  There is another table "ВерсияВнешнегоДокумента$Документ" (without ^lob.)
>>>  It is referenced by a foreign key ("rlob.ВерсияВнешнегоДокумента$Документ-@Файл")
>>>  But as I understand it, the problem with the primary key.
>>  Does the old database have a table with prefix "plob.", called
>>  plob.ВерсияВнешнегоДокумента$Документ?
>>
>>  If not, if you do pg_dumpall --schema-only --binary-upgrade, is there a
>>  table with that name mentioned?
>
> Also, when you say "rlob" above, is the 'r' a Latin letter sound that
> would look like a Russian 'p' in the error message?  (In Cyrillic, a
> Latin-looking p sounds like Latin-sounding r.)
>
> --
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
>   + It's impossible for everything to be true. +