From: KaiGai Kohei on
(2009/12/17 13:20), Robert Haas wrote:
> 2009/12/16 KaiGai Kohei<kaigai(a)ak.jp.nec.com>:
>> (2009/12/17 7:25), Robert Haas wrote:
>>> On Thu, Dec 10, 2009 at 10:41 PM, Takahiro Itagaki
>>> <itagaki.takahiro(a)oss.ntt.co.jp> wrote:
>>>>
>>>> KaiGai Kohei<kaigai(a)ak.jp.nec.com> wrote:
>>>>
>>>>> What's your opinion about:
>>>>> long desc: When turned on, privilege checks on large objects perform with
>>>>> backward compatibility as 8.4.x or earlier releases.
>>>>
>>>> I updated the description as your suggest.
>>>>
>>>> Applied with minor editorialization,
>>>> mainly around tab-completion support in psql.
>>>
>>> The documentation in this patch needs work.
>>
>> Are you talking about English quality? or Am I missing something to be
>> documented?
>
> Mostly English quality, but there are some other issues too. Proposed
> patch attached.

I have nothing to comment on English quality....

Thanks for your fixups.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
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: Takahiro Itagaki on

Robert Haas <robertmhaas(a)gmail.com> wrote:

> 2009/12/16 KaiGai Kohei <kaigai(a)ak.jp.nec.com>:
> >>>> ? ?long desc: When turned on, privilege checks on large objects perform with
> >>>> ? ? ? ? ? ? ? backward compatibility as 8.4.x or earlier releases.

> Mostly English quality, but there are some other issues too. Proposed
> patch attached.

I remember we had discussions about the version number, like
"Don't use '8.5' because it might be released as '9.0'", no?

Another comment is I'd like to keep <link linkend="catalog-pg-largeobject-metadata">
for the first <structname>pg_largeobject</structname> in each topic.

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

From: Robert Haas on
2009/12/17 Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp>:
>
> Robert Haas <robertmhaas(a)gmail.com> wrote:
>
>> 2009/12/16 KaiGai Kohei <kaigai(a)ak.jp.nec.com>:
>> >>>> ? ?long desc: When turned on, privilege checks on large objects perform with
>> >>>> ? ? ? ? ? ? ? backward compatibility as 8.4.x or earlier releases.
>
>> Mostly English quality, but there are some other issues too.  Proposed
>> patch attached.
>
> I remember we had discussions about the version number, like
> "Don't use '8.5' because it might be released as '9.0'", no?

I chose to follow the style which Tom indicated that he preferred
here. We don't use the phrase "8.4.x series" anywhere else in the
documentation, so this doesn't seem like a good time to start. Tom or
I will go through and renumber everything if we end up renaming the
release to 9.0.

> Another comment is I'd like to keep <link linkend="catalog-pg-largeobject-metadata">
> for the first <structname>pg_largeobject</structname> in each topic.

Those two things aren't the same. Perhaps you meant <link
linkend="catalog-pg-largeobject">? I'll tweak the pg_largeobject and
pg_largeobject_metadata sections to make sure each has a link to the
other and commit this. I also found one more spelling mistake so I
will include that correction as well.

....Robert

--
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: Takahiro Itagaki on

Robert Haas <robertmhaas(a)gmail.com> wrote:

> > Another comment is I'd like to keep <link linkend="catalog-pg-largeobject-metadata">
> > for the first <structname>pg_largeobject</structname> in each topic.
>
> Those two things aren't the same. Perhaps you meant <link
> linkend="catalog-pg-largeobject">?

Oops, yes. Thank you for the correction.

We also have "8.4.x series" in the core code. Do you think we also
rewrite those messages? One of them is an use-visible message.

LargeObjectAlterOwner() : pg_largeobject.c
* The 'lo_compat_privileges' is not checked here, because we
* don't have any access control features in the 8.4.x series
* or earlier release.
* So, it is not a place we can define a compatible behavior.

guc.c
{"lo_compat_privileges", PGC_SUSET, COMPAT_OPTIONS_PREVIOUS,
gettext_noop("Enables backward compatibility in privilege checks on large objects"),
gettext_noop("When turned on, privilege checks on large objects perform "
"with backward compatibility as 8.4.x or earlier releases.")


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

From: Robert Haas on
On Thu, Dec 17, 2009 at 7:27 PM, Takahiro Itagaki
<itagaki.takahiro(a)oss.ntt.co.jp> wrote:
>> > Another comment is I'd like to keep <link linkend="catalog-pg-largeobject-metadata">
>> > for the first <structname>pg_largeobject</structname> in each topic.
>> Those two things aren't the same.  Perhaps you meant <link
>> linkend="catalog-pg-largeobject">?
> Oops, yes. Thank you for the correction.
>
> We also have "8.4.x series" in the core code. Do you think we also
> rewrite those messages? One of them is an use-visible message.

Yes. I started going through the comments tonight. Partial patch
attached. There were two comments that I was unable to understand and
therefore could not reword - the one at the top of
pg_largeobject_aclmask_snapshot(), and the second part of the comment
at the top of LargeObjectExists():

* Note that LargeObjectExists always scans the system catalog
* with SnapshotNow, so it is unavailable to use to check
* existence in read-only accesses.

In both cases, I'm lost. Help?

In acldefault(), there is this comment:

/* Grant SELECT,UPDATE by default, for now */

This doesn't seem to match what the code is doing, so I think we
should remove it.

I also notice that dumpBlobComments() is now misnamed, but it seems
we've chosen to add a comment
mentioning that fact rather than fixing it. That doesn't seem like
the right approach.

....Robert
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: explain output infelicity in psql
Next: Winflex