(2010/02/09 20:16), Takahiro Itagaki wrote:
> KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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.
> 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).
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.
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
In response to
pgsql-hackers by date
|Next:||From: Michael Meskes||Date: 2010-02-09 12:21:25|
|Subject: Re: buildfarm breakage|
|Previous:||From: Jeroen Vermeulen||Date: 2010-02-09 12:08:54|
|Subject: Avoiding bad prepared-statement plans.|