Prev: explain output infelicity in psql
Next: Winflex
From: KaiGai Kohei on 16 Dec 2009 23:57 (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 17 Dec 2009 00:10 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 17 Dec 2009 09:16 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 17 Dec 2009 19:27 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 17 Dec 2009 23:11
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 |