Re: [PATCH] Largeobject access controls - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: [PATCH] Largeobject access controls
Date
Msg-id 3073cc9b0909202332kc2fce71padb18fba7754c1d2@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Largeobject access controls  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: [PATCH] Largeobject access controls
List pgsql-hackers
2009/9/6 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> The attached patch is an update of largeobject access controls.
>

it applies fine (just 3 succeded hunks), compiles and passes
regression tests...

ALTER LARGE OBJECT is working, but now that we can change the owner of
a LO we should be able to see who the actual owner is... i mean we
should add an owner column in \dl for psql (maybe \dl+) and maybe an
lo_owner() function.

the GRANTs (and REVOKEs) work just fine too...
Another question is what we want that only the LO owner can delete it
(via lo_unlink)?

another one, is it possible for us to have a CREATE LARGE OBJECT statement?
the reason for this is:
1) it is a little ugly to use the OID in ALTER/GRANT/REVOKE
statements, in a create statement we can assign a name to the LO
2) it could be more consistent with other ALTER/GRANT/REVOKE that acts
over objects created with CREATE while large objects are created via
lo_import() which makes obvious that are just records in meta-data
table (hope this is understandable)


> It adds a new guc variable to turn on/off compatible behavior in
> largeobejct access controls.
>
>  largeobject_compat_dac = [on | off] (default: off)
>
> If the variable is turned on, all the new access control features
> on largeobjects are bypassed, as if v8.4.x or prior did.

the GUC works as intended
but i don't like the name, it is not very meaningful for those of us
that doesn't know what DAC or MAC are...
another point, you really have to put the GUC in the postgresql.conf
file if you hope people know about it ;)
it is not documented either


About the code...
- I don't like the name pg_largeobject_meta why not pg_largeobject_acl
(put here any other name you like)? or there was a reason for that
choose?

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: TODO item: Allow more complex user/database default GUC settings
Next
From: Jeevan Chalke
Date:
Subject: Re: numeric_to_number() function skipping some digits