Skip site navigation (1) Skip section navigation (2)

Re: Largeobject Access Controls (r2460)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Largeobject Access Controls (r2460)
Date: 2010-02-02 04:49:52
Message-ID: 4B67AEF0.5020408@ak.jp.nec.com (view raw or flat)
Thread:
Lists: pgsql-hackers
>>> The --schema-only with large objects might be unnatural, but the
>>> --data-only with properties of large objects are also unnatural.
>>> Which behavior is more unnatural?
>>
>> I think large object metadata is a kind of row-based access controls.
>> How do we dump and restore ACLs per rows when we support them for
>> normal tables? We should treat LO metadata as same as row-based ACLs.
>> In my opinion, I'd like to treat them as part of data (not of schema).
> 
> OK, I'll update the patch according to the behavior you suggested.
> | I'd prefer to keep the existing behavior:
> |   * default or data-only : dump all attributes and data of blobs
> |   * schema-only          : don't dump any blobs
> | and have independent options to control blob dumps:
> |   * -b, --blobs    : dump all blobs even if schema-only
> |   * -B, --no-blobs : [NEW] don't dump any blobs even if default or data-only

I found out it needs special treatments to dump comments and access
privileges of blobs. See dumpACL() and dumpComment()

| static void
| dumpACL(Archive *fout, CatalogId objCatId, DumpId objDumpId,
|         const char *type, const char *name, const char *subname,
|         const char *tag, const char *nspname, const char *owner,
|         const char *acls)
| {
|     PQExpBuffer sql;
|
|     /* Do nothing if ACL dump is not enabled */
|     if (dataOnly || aclsSkip)
|         return;
|     :

| static void
| dumpComment(Archive *fout, const char *target,
|             const char *namespace, const char *owner,
|             CatalogId catalogId, int subid, DumpId dumpId)
| {
|     CommentItem *comments;
|     int         ncomments;
|
|     /* Comments are SCHEMA not data */
|     if (dataOnly)
|         return;
|     :

In addition, _printTocEntry() is not called with acl_pass = true,
when --data-only is given.

I again wonder whether we are on the right direction.

Originally, the reason why we decide to use per blob toc entry was
that "BLOB ACLS" entry needs a few exceptional treatments in the code.
But, if we deal with "BLOB ITEM" entry as data contents, it will also
need additional exceptional treatments.

Indeed, even if we have row-level ACLs, it will be dumped in data section
without separating them into properties and data contents because of the
restriction on implementation, not a data modeling reason.

Many of empty large objects may not be sane situation, but it is suitable
for the existing manner in pg_dump/pg_restore, at least.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

pgsql-hackers by date

Next:From: Takahiro ItagakiDate: 2010-02-02 05:28:32
Subject: Re: New VACUUM FULL crashes on temp relations
Previous:From: Fujii MasaoDate: 2010-02-02 04:40:14
Subject: Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group