Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
On Wed, May 5, 2021 at 7:03 PM Laurenz Albe wrote: > > On Mon, 2021-05-03 at 13:48 -0300, Martín Marqués wrote: > > We should add a line that indicates that there is a limitation (that > > should be IMO, backported to documentation of earlier versions as it > > affects all supported versions), at least until such limitation is > > lifted. > > Here is a patch for that, The patch adds the description in the autovacuum_work_mem section. Isn't it better to add it in mantenance_work section or VACUUM command section since this limitation is not only for autovacuum? Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
Re: Note that ALTER TABLE cannot alter generated stored columns
On 30.05.21 15:25, Emre Hasegeli wrote: I was trying to change the generation expression of a generated stored column using ALTER TABLE. It took me a while before I figured SET GENERATED applies only to generated identity columns. I think it'd be useful to note this in the documentation with something like the attached. I don't follow why you put this documentation under ALTER TABLE ... DROP EXPRESSION. That action doesn't seem related to what you were hoping to do.
Re: Simplify COMMENT and SECURITY LABEL documentation
On 01.06.21 17:56, Alvaro Herrera wrote: +1 for the concept, but I feel that "live in" is a bit too informal for this context. I'm too caffeine-deprived to instantly come up with le mot juste; but perhaps "exist within" would be an improvement? The glossary uses "reside in". I like that. I suppose that we should either use the same term that the glossary uses, or alternatively fix the glossary to use whatever term we decide to use here. I do notice now that I used the term "belong to" elsewhere in the glossary. That could use some cleanup. I think "belong to" is a stronger relationship, like a column belongs to a table. Kind of like DEPENDENCY_INTERNAL vs. DEPENDENCY_NORMAL.
Re: Simplify COMMENT and SECURITY LABEL documentation
Peter Eisentraut writes: > On 01.06.21 17:56, Alvaro Herrera wrote: >> The glossary uses "reside in". > I like that. > I think "belong to" is a stronger relationship, like a column belongs to > a table. Kind of like DEPENDENCY_INTERNAL vs. DEPENDENCY_NORMAL. Hmm, okay. I can support "reside in". regards, tom lane
Re: Simplify COMMENT and SECURITY LABEL documentation
On 2021-Jun-02, Peter Eisentraut wrote: > On 01.06.21 17:56, Alvaro Herrera wrote: > > > +1 for the concept, but I feel that "live in" is a bit too informal > > > for this context. I'm too caffeine-deprived to instantly come up > > > with le mot juste; but perhaps "exist within" would be an improvement? > > > > The glossary uses "reside in". > > I like that. So I would adjust the glossary as in the attached patch. -- Álvaro Herrera Valdivia, Chile "Ed is the standard text editor." http://groups.google.com/group/alt.religion.emacs/msg/8d94ddab6a9b0ad3 diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml index 41f3e5ee86..c8d0440e80 100644 --- a/doc/src/sgml/glossary.sgml +++ b/doc/src/sgml/glossary.sgml @@ -1448,7 +1448,7 @@ known as local objects. - Most local objects belong to a specific + Most local objects reside in a specific schema in their containing database, such as relations (all types), @@ -1458,7 +1458,7 @@ are enforced to be unique. - There also exist local objects that do not belong to schemas; some examples are + There also exist local objects that do not reside in schemas; some examples are extensions, data type casts, and foreign data wrappers.
