(2010/02/09 20:16), Takahiro Itagaki wrote:
KaiGai Kohei<kai...@ak.jp.nec.com> wrote:
I don't think this is necessarily a good idea. We might decide to treat
both things separately in the future and it having them represented
separately in the dump would prove useful.
I agree. From design perspective, the single section approach is more
simple than dual section, but its change set is larger than the dual.
OK.
When I tested a custom dump with pg_restore, --clean& --single-transaction
will fail with the new dump format because it always call lo_unlink()
even if the large object doesn't exist. It comes from dumpBlobItem:
! dumpBlobItem(Archive *AH, BlobInfo *binfo)
! appendPQExpBuffer(dquery, "SELECT lo_unlink(%s);\n", binfo->dobj.name);
The query in DropBlobIfExists() could avoid errors -- should we use it here?
| SELECT lo_unlink(oid) FROM pg_largeobject_metadata WHERE oid = %s;
Yes, we can use this query to handle --clean option.
I'll fix it soon.
BTW, --clean option is ambiguous if combined with --data-only. Restoring
large objects fails for the above reason if previous objects don't exist,
but table data are restored *without* truncation of existing data. Will
normal users expect TRUNCATE-before-load for --clean& --data-only cases?
Present behaviors are;
Table data - Appended. (--clean is ignored)
Large objects - End with an error if object doesn't exist.
IMO, ideal behaviors are:
Table data - Truncate existing data and load new ones.
Large objects - Work like as MERGE (or REPLACE, UPSERT).
Comments?
In the existing "BLOBS" section, it creates and restores large objects
in same time. And, it also unlink existing large object (if exists)
just before restoring them, when --clean is given.
In my opinion, when --clean is given, it also should truncate the table
before restoring, even if --data-only is co-given.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
