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 INITIALLY IMMEDIATE
)
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" <br...@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 <br...@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
