Doc patch, normalize search_path in index
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting.
"search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
It's hard to say whether it's useful to make this
distinction. From a practical perspective it's easy
for the eye to stop scanning when the indent
level changes and so fail to notice that both
"search path" and "search_path" are index
entries. At least the index is a
lot more tidy than before.
Regards,
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Attachments:
search_path-normalize.patchtext/x-patch; charset=us-ascii; name=search_path-normalize.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d5bd993..5671ddf 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4758,7 +4758,8 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<varlistentry id="guc-search-path" xreflabel="search_path">
<term><varname>search_path</varname> (<type>string</type>)</term>
<indexterm>
- <primary><varname>search_path</> configuration parameter</primary>
+ <primary><varname>search_path</></primary>
+ <secondary>configuration parameter</secondary>
</indexterm>
<indexterm><primary>path</><secondary>for schemas</></>
<listitem>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index d6e5d64..367dce7 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1736,6 +1736,7 @@ CREATE TABLE public.products ( ... );
<indexterm>
<primary>search_path</primary>
+ <secondary>run-time setting</secondary>
</indexterm>
<para>
On Fri, Sep 28, 2012 at 1:40 PM, Karl O. Pinc <kop@meme.com> wrote:
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting.
Makes sense to me, although I suspect the conceptual material is
better served by the "search path"-the-concept index entry and the
reference material by the "search_path configuration parameter" entry
(so, from that perspective, perhaps the patch should just be to remove
the "search_path" index entry from the DDL schemas conceptual
section).
"search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
It's hard to say whether it's useful to make this
distinction.
I think that indexing "search path"-the-concept is useful for
translations, and the Japanese translation includes an index (I
couldn't find the index for the French translation).
--
Dan Scott
Laurentian University
On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting."search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
It's hard to say whether it's useful to make this
distinction. From a practical perspective it's easy
for the eye to stop scanning when the indent
level changes and so fail to notice that both
"search path" and "search_path" are index
entries. At least the index is a
lot more tidy than before.
I have applied a modified version of your patch that creates separate
secondary index references for search_path.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
search_path.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index b7df8ce..5f47c1f
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** COPY postgres_log FROM '/full/path/to/lo
*** 4778,4784 ****
<varlistentry id="guc-search-path" xreflabel="search_path">
<term><varname>search_path</varname> (<type>string</type>)</term>
<indexterm>
! <primary><varname>search_path</> configuration parameter</primary>
</indexterm>
<indexterm><primary>path</><secondary>for schemas</></>
<listitem>
--- 4778,4785 ----
<varlistentry id="guc-search-path" xreflabel="search_path">
<term><varname>search_path</varname> (<type>string</type>)</term>
<indexterm>
! <primary><varname>search_path</></primary>
! <secondary>configuration parameter</secondary>
</indexterm>
<indexterm><primary>path</><secondary>for schemas</></>
<listitem>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
new file mode 100644
index 207de9b..929d29c
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
*************** CREATE TABLE public.products ( ... );
*** 1735,1741 ****
</para>
<indexterm>
! <primary><varname>search_path</varname> configuration parameter</primary>
</indexterm>
<para>
--- 1735,1742 ----
</para>
<indexterm>
! <primary><varname>search_path</varname></primary>
! <secondary>run-time setting</secondary>
</indexterm>
<para>
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
new file mode 100644
index 48160b2..1f6c134
*** a/doc/src/sgml/ref/create_function.sgml
--- b/doc/src/sgml/ref/create_function.sgml
*************** SELECT * FROM dup(42);
*** 674,680 ****
<title>Writing <literal>SECURITY DEFINER</literal> Functions Safely</title>
<indexterm>
! <primary><varname>search_path</varname> configuration parameter</>
<secondary>use in securing functions</>
</indexterm>
--- 674,680 ----
<title>Writing <literal>SECURITY DEFINER</literal> Functions Safely</title>
<indexterm>
! <primary><varname>search_path</varname></>
<secondary>use in securing functions</>
</indexterm>
Bruce Momjian <bruce@momjian.us> writes:
I have applied a modified version of your patch that creates separate
secondary index references for search_path.
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two different places for those two terms?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have applied a modified version of your patch that creates separate
secondary index references for search_path.This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two different places for those two terms?
I think he is trying to distinguish between the parameter and the
setting of the parameter, and also its use for security. No one really
replied to the email so I thought the distinction was accpetable.
Should I make them both "configuration parameter" and leave the
"security" as a second one separate?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two different places for those two terms?
Should I make them both "configuration parameter" and leave the
"security" as a second one separate?
Works for me. I think "configuration parameter" is the phrase we
use most places.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 25, 2013 at 01:42:48PM -0500, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two different places for those two terms?Should I make them both "configuration parameter" and leave the
"security" as a second one separate?Works for me. I think "configuration parameter" is the phrase we
use most places.
OK, attached patch applied.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
search_path2.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
new file mode 100644
index 929d29c..f869b50
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
*************** CREATE TABLE public.products ( ... );
*** 1736,1742 ****
<indexterm>
<primary><varname>search_path</varname></primary>
! <secondary>run-time setting</secondary>
</indexterm>
<para>
--- 1736,1742 ----
<indexterm>
<primary><varname>search_path</varname></primary>
! <secondary>configuration parameter</secondary>
</indexterm>
<para>
On 1/25/13 12:50 PM, Bruce Momjian wrote:
On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting."search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
It's hard to say whether it's useful to make this
distinction. From a practical perspective it's easy
for the eye to stop scanning when the indent
level changes and so fail to notice that both
"search path" and "search_path" are index
entries. At least the index is a
lot more tidy than before.I have applied a modified version of your patch that creates separate
secondary index references for search_path.
This matter was already closed:
https://commitfest.postgresql.org/action/patch_view?id=949
It looks like your patch reverts part of that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
On 1/25/13 12:50 PM, Bruce Momjian wrote:
On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
Hi,
The attached patch (against git head)
normalizes "search_path" as the thing indexed
and uses a secondary index term to distinguish
the configuration parameter from the run-time
setting."search path" the concept remains distinguished
in the index from "search_path" the setting/config param.
It's hard to say whether it's useful to make this
distinction. From a practical perspective it's easy
for the eye to stop scanning when the indent
level changes and so fail to notice that both
"search path" and "search_path" are index
entries. At least the index is a
lot more tidy than before.I have applied a modified version of your patch that creates separate
secondary index references for search_path.This matter was already closed:
https://commitfest.postgresql.org/action/patch_view?id=949It looks like your patch reverts part of that.
Uh, I am confused because the patch at:
https://commitfest.postgresql.org/action/patch_view?id=950
/messages/by-id/1352874080.4647.0@mofo
shows "configuration parameter" being moved to <secondary>, though this
commit:
shows it not as secondary. Would you please suggest a patch or patch
it? Thanks.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 01/25/2013 12:35:49 PM, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I have applied a modified version of your patch that creates
separate
secondary index references for search_path.
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two different places for those two terms?
One was the setting/querying of the parameter, the other the
purpose/impact of the setting. Somewhere in there I'm also
thinking it's a matter of the lexical token used v.s.
the functionality manipulated. One would have an _ in
between the words of the index entry, the other wouldn't.
The distinction would get all messed up by the browser
when it underlined hyperlinks.
I no longer recall the point
in making the distinction, although I believe that it came
from something to do with the vocabulary already in place
involving indexing settings and what they do. Or maybe I made it up.
In any case I don't think that the patch the Peter pushed
when he closed the commitfest entry made any distinction
between the token and the concept. Given that the difference
in sort order is the presence/absence of an _, and the
way hyperlinks are represented, I think this made the
the resulting index look best.
There was also a "use of search path to secure functions"
indexing wrapped in with the rest of the patch.
Hope this helps.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1/25/13 1:59 PM, Bruce Momjian wrote:
On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
This matter was already closed:
https://commitfest.postgresql.org/action/patch_view?id=949It looks like your patch reverts part of that.
Uh, I am confused because the patch at:
https://commitfest.postgresql.org/action/patch_view?id=950
/messages/by-id/1352874080.4647.0@mofoshows "configuration parameter" being moved to <secondary>, though this
commit:
The discussion yielded a patch that is different from the commit fest entry.
We index all GUC settings as
<primary><varname>something</varname> configuration parameter</primary>
which the commit a301eb99c9537186f7dd46ba418e84d755227a94 also made the case for search_path.
Your two commits changed that again.
shows it not as secondary. Would you please suggest a patch or patch
it? Thanks.
I think both of your commits should be reverted.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 25, 2013 at 05:10:14PM -0500, Peter Eisentraut wrote:
On 1/25/13 1:59 PM, Bruce Momjian wrote:
On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
This matter was already closed:
https://commitfest.postgresql.org/action/patch_view?id=949It looks like your patch reverts part of that.
Uh, I am confused because the patch at:
https://commitfest.postgresql.org/action/patch_view?id=950
/messages/by-id/1352874080.4647.0@mofoshows "configuration parameter" being moved to <secondary>, though this
commit:The discussion yielded a patch that is different from the commit fest entry.
We index all GUC settings as
<primary><varname>something</varname> configuration parameter</primary>
which the commit a301eb99c9537186f7dd46ba418e84d755227a94 also made the case for search_path.
Your two commits changed that again.
shows it not as secondary. Would you please suggest a patch or patch
it? Thanks.I think both of your commits should be reverted.
I now see the pattern. Thanks. Patches reverted.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers