Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEnHE-0001ag-64 for pgsql-docs@arkaria.postgresql.org; Fri, 12 Apr 2019 03:54:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hEnHC-0000f1-Tf for pgsql-docs@arkaria.postgresql.org; Fri, 12 Apr 2019 03:54:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEnHC-0000eR-FB for pgsql-docs@lists.postgresql.org; Fri, 12 Apr 2019 03:54:54 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hEnH5-0004OP-8y for pgsql-docs@postgresql.org; Fri, 12 Apr 2019 03:54:53 +0000 Received: by mail-qt1-x844.google.com with SMTP id s15so9768426qtn.3 for ; Thu, 11 Apr 2019 20:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=yMtytpz7pJc/er8yd8ii2Ob/YWzu1DageQjj8AVWuAQ=; b=ytnWLNdrk8Xf6gU/Rwb+Dktla0dfNY8mHGtsLD7+Lgdxh8IkZ31gQcrEEAfmrhXMG5 t7xAB0Z3oEwXoqxllPcrjNqOkEIPAw+Mmcvrzv4qSlicPGe2RHlCzRaxtVhEXgeAazgC v8BJ48sTcdzvyblqqRu1i0ZbGCdE+c9reflp299IOF6jpPt6JSMZ9VRZRB8BCScbkEZ0 h2MAvPOrLkrOvyeAi4HaHM+A1DNNNVumMWPHo444A6HywSLU08mNFU+zwZuV0evql63w RQbBL3B2auWPtBJ8p/URrY8BpdK+/3RspGq8jctSxDTNojc6w3a2suA1d++vUSV6pMrX XG0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=yMtytpz7pJc/er8yd8ii2Ob/YWzu1DageQjj8AVWuAQ=; b=t33EdxI2PglknzkYrXd+LUOXenRPFTZifabnbusy8ydbhXhH9ScG+p9LYZGaMoG9Hh SgvTxrith2DWK7z96RVh1wCRVpc8jJy2+VuFeVxy7rFRkC44O5P9JHK8oxm+3hv9aDhR QiNMbTOFcpZ1WlexCLL3kRpHzmbmL0byiWtL81P7VwLZU4I8W5wMBYdP5h/efHhaL1ca 3w96HW4l94PEhdp1oum9g61C8t1O5+qQSoib1mAC1QjWyYHPrz6AdwpZtjMNf8hHO92e fnsXeJnii0T9zaTpM/iApxo9ClbF/wR6Pws75PTn6Xfm1kd2nCMFqJet69grxVbh+VXb xOpg== X-Gm-Message-State: APjAAAWrU1M9+oWANG5dsYQFznx9uTnTr35Gx2u7DGvqoUEcJ4k65uIy W+H2LruqQFsJRPPooaYiPmaxh3Uz85g= X-Google-Smtp-Source: APXvYqwU+TzvFj3Ae9Tytbq1RGxVcNFpvmRP1cp3Ag8W2fhppsIGtl8tAaJx7bGc5nueRiavXOLDew== X-Received: by 2002:ac8:3844:: with SMTP id r4mr45027011qtb.5.1555041286436; Thu, 11 Apr 2019 20:54:46 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([201.186.80.67]) by smtp.gmail.com with ESMTPSA id z9sm28131484qtb.73.2019.04.11.20.54.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Apr 2019 20:54:45 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 2548D12120D; Thu, 11 Apr 2019 23:54:44 -0400 (-04) Date: Thu, 11 Apr 2019 23:54:44 -0400 From: Alvaro Herrera To: Fujii Masao Cc: pgsql-docs Subject: Re: Mark a reloption as indexterm Message-ID: <20190412035444.GA3623@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Apr-12, Fujii Masao wrote: > On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera wrote: > > > > On 2019-Apr-10, Fujii Masao wrote: > > > > > Hi, > > > > > > I'd like to propose to mark reloptions as indexterms, like GUC, > > > so that users can more easily search the pages describing > > > a reloption in document. Attached is the patch which does this. > > > Is this helpful? Thought? > > > > +1 for adding index entries to all reloptions. I'm not sure what you're > > achieving by splitting the text for some existing index entries in two > > and putting two words in the that were part of the > > , though. I'd just put the whole text in (obviously > > the option name must be the first word of that). > > Indeed. Attached is the updated version of the patch. Hmm, actually, I now see you were originally proposing the words "storage parameter" for the fillfactor index entries, but for v2 you instead copied the "configuration parameter" words that was in some other of the older entries. I think "configuration parameter" is wrong (we use that for GUCs, and it seems to me that it would be confusing to mix both things), and we should use the words "storage parameter" for all of these, don't you think? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services