Largeobject Access Controls (r2460)
in [PgSql]
|
Prev: [HACKERS] is any reason why we cannot cast from record (row) to typed row?
Next: [HACKERS] 8.5 vs. 9.0
From: KaiGai Kohei on 9 Feb 2010 07:18 (2010/02/09 20:16), Takahiro Itagaki wrote: > > KaiGai Kohei<kaigai(a)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 <kaigai(a)kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 9 Feb 2010 19:39 (2010/02/09 21:18), KaiGai Kohei wrote: > (2010/02/09 20:16), Takahiro Itagaki wrote: >> >> KaiGai Kohei<kaigai(a)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. The attached patch fixed up the cleanup query as follows: + appendPQExpBuffer(dquery, + "SELECT pg_catalog.lo_unlink(oid) " + "FROM pg_catalog.pg_largeobject_metadata " + "WHERE oid = %s;\n", binfo->dobj.name); And, I also noticed that lo_create() was not prefixed by "pg_catalog.", so I also add it. Rest of parts were not changed. Thanks, >> 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, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com>
From: Takahiro Itagaki on 9 Feb 2010 21:26
KaiGai Kohei <kaigai(a)ak.jp.nec.com> wrote: > The attached patch fixed up the cleanup query as follows: > + appendPQExpBuffer(dquery, > + "SELECT pg_catalog.lo_unlink(oid) " > + "FROM pg_catalog.pg_largeobject_metadata " > + "WHERE oid = %s;\n", binfo->dobj.name); > > And, I also noticed that lo_create() was not prefixed by "pg_catalog.", > so I also add it. Thanks. Now the patch is ready to commit. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |