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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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